Since the release of Log Analyzer 2019.4 , there have been a lot of things going on behind the scenes here at SolarWinds. Everything from new LA specific features to Orion platform enhancements are in the works! See below: Flat log file ingestion - Collect flat logs from applications running on Orion nodes utilizing the Orion agent. Continued feature parity work for syslogs and traps Analytics - we want to find problems you didn't know you have, by leveraging machine learning capabilities to detect anomalies in your log data. Sub-string Extraction - Create custom metrics and identify strings to be used as variables in alerting etc. New dashboard framework - Next generation summary dashboard framework. UI performance optimizations - Faster and more responsive web UI. Centralized upgrades - Pre-stage upgrades for reduced downtime. Orion maps - Bridging the feature parity gap with Network Atlas. As always we welcome your input! If you have an idea for Log Analyzer be sure to post it in our feature request forum .

This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.

You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

What We’re Working on for Log Analyzer (Updated Nov 13, 2019)

solarwinds_worldwide_llc over 5 years ago

Since the release of Log Analyzer 2019.4, there have been a lot of things going on behind the scenes here at SolarWinds. Everything from new LA specific features to Orion platform enhancements are in the works! See below:

Flat log file ingestion - Collect flat logs from applications running on Orion nodes utilizing the Orion agent.
Continued feature parity work for syslogs and traps
Analytics - we want to find problems you didn't know you have, by leveraging machine learning capabilities to detect anomalies in your log data.
Sub-string Extraction - Create custom metrics and identify strings to be used as variables in alerting etc.
New dashboard framework - Next generation summary dashboard framework.
UI performance optimizations - Faster and more responsive web UI.
Centralized upgrades - Pre-stage upgrades for reduced downtime.
Orion maps - Bridging the feature parity gap with Network Atlas.

As always we welcome your input! If you have an idea for Log Analyzer be sure to post it in our feature request forum.

Top Replies

Parents

0 planglois over 4 years ago

We use Solarwinds to aggregate traps & syslogs (Mostly traps) from private production sub networks. We filter some traps (Mostly the informational traps) and forward the remaining to our National NOC. The source IP of the trap identiify the network it came from to ensure proper treatment at the NOC.
Also, we use forwarding in our setup to palliate a lack of feature in Solarwinds. Let me explain:
We currently have a main Orion server and 2 additional pollers. Each additionnal poller is dedidated to a specific network. When a trap is coming to the AP, the AP forwards the trap, and based on source IP, the National NOC is treating the information.
When we generate a trap on an alert (i.e.: Node is down), even if the node is managed by one of the additional pollers, the trap is sent by the main Orion server. Since a part of our NOC workflow uses the source IP of trap to Identify the corresponding network, sending it from the main Orion server gets us into trouble... To bypass this issue, we send the alarm trap to 127.0.0.1, then we then have a rule that tag the trap and forward the trap to the AP. That AP would then forward the trap to the NOC with appropriate source IP so the alarms could be treated accordingly...
I have to maintain a Visio workflow diagram due to the many rules and Orion servers we have. it is time consuming and not really ideal. I hope this would change in LM one day.
Cancel
Vote Up 0 Vote Down

Cancel

Reply

0 planglois over 4 years ago

We use Solarwinds to aggregate traps & syslogs (Mostly traps) from private production sub networks. We filter some traps (Mostly the informational traps) and forward the remaining to our National NOC. The source IP of the trap identiify the network it came from to ensure proper treatment at the NOC.
Also, we use forwarding in our setup to palliate a lack of feature in Solarwinds. Let me explain:
We currently have a main Orion server and 2 additional pollers. Each additionnal poller is dedidated to a specific network. When a trap is coming to the AP, the AP forwards the trap, and based on source IP, the National NOC is treating the information.
When we generate a trap on an alert (i.e.: Node is down), even if the node is managed by one of the additional pollers, the trap is sent by the main Orion server. Since a part of our NOC workflow uses the source IP of trap to Identify the corresponding network, sending it from the main Orion server gets us into trouble... To bypass this issue, we send the alarm trap to 127.0.0.1, then we then have a rule that tag the trap and forward the trap to the AP. That AP would then forward the trap to the NOC with appropriate source IP so the alarms could be treated accordingly...
I have to maintain a Visio workflow diagram due to the many rules and Orion servers we have. it is time consuming and not really ideal. I hope this would change in LM one day.
Cancel
Vote Up 0 Vote Down

Cancel

Children

No Data