cancel
Showing results for 
Search instead for 
Did you mean: 
Create Post

what we are working on for NTA after v3.11

Level 11

Hello!

After the release of NTA 3.11 we here at SolarWinds turn our focus on performance and retention with in NTA. There have been several surveys that you all have been great about providing feedback on in addition to here on Thwack. Survey Says: make it run faster! Retain my data longer! You asked, we listened and now we are focused on delivering our next release with these enhancements as the primary focus.

  • Performance:
    • Decreasing Web Page Load Times
    • Decreasing Flow Processing overhead
    • Increasing Flow Processing speed and capacity
    • Decreasing SQL DB overhead
  • Retention:
    • No more data aggregation
    • Greatly increased detailed data retention

And for all you Juniper folks, we're also planning on supporting sampled jFlow. Stay tuned for more updates about beta builds in the near future! Can't be contained in 4.0

Disclaimer: This is not a commitment to a time frame or delivery of any of the features discussed below. This is also not a commitment to deliver all of these features in our next release. This post is intended to give you a rough idea of what we're doing.

25 Comments
Level 14

And for all you Juniper folks, we're also planning on supporting sampled jFlow. Stay tuned for more updates about beta builds in the near future!

Oh happy day!  My Juniper gear will no longer feel like the red headed step child that no one wants to acknowledge is at the party.

Level 8

excellent news on the data retention!  it means we no longer have to do complex exports to a central data warehouse!  all we have to do is get more disk space - and we have lots of that!!!

Level 13

Are there any plans to be able to seperate the NTA database and the NPM database? That separation alone would help with performance of contention modules.

Level 11

Hi Steven, Yes! part of the work we are doing is removing the flow storage and processing from the NPM SQL DB. NTA will still need to maintain a connection to the NPM for CBQoS data and a few other smaller things but the large burden of storing and processing flow data into the NPM DB will be alleviated.

Level 14

I must say you are listening us after all. Good for you. And thanks. Don't forget to support sampled sflow also. Juniper routers supports sflow and jflow.

Level 14

We are not using CBQoS. Actually we don't have any cisco at all. All juniper now. Long live juniper.

Level 13

IIMHO, performance will also be improved once the Orion engine front engine is upgraded.

it needs to move to a modern web rendering engine. Look at google maps. See how the page does not keep on updating when you move the map. Just the changes get updated

Level 12


Very happy to hear about the "Decreasing Web Page Load Times". This is without a doubt the web page that takes the longest to load for us. Its always when someone whats to know "who is using all the bandwidth"

Level 14

Don't forget to support IPFIX from netscaler.

Level 9

So does this mean for CBQOS you are looking at dramatically increasing the data retention for this? At the moment that part of the tool is esssentially useless for us, as we want to use it for capacity planning and historical troubleshooting.

Level 16

The change to a dedicated database for the netflow data while appreciated is a significant architectural chnage that will affect large deployments. For example our SQL server is designed for high write throughput, but the [application server] hardware we run NTA on does not have enough local storage for this product upgrade.

Can the NTA database engine be run in the SQL Server hardware?

MVP
MVP

we have a fancy new server for npm & nta, as well as a nice big sql server... yet nta takes forever to load and is super slow to use...

our solution... setup NFSEN on a 7 year old laptop and leave it under the desk...

now we use nta as a secondary source of info, and nfsen as our primary source..

also nfsen = $000 = FREE...

Level 16

Does this mean I need a new SQL server?  Would I see performance increases if it is a server on the same instance?  Are there any reccomendations for optimal performance?

Thanks....

Level 11

Hey there, you will not need a new SQL server to support the NTA Flow Storage Database. This can be installed in parallel on the same machine as your SQL DB. Additionally the Flow Storage DB can be installed on your main poller, or on any other machine on your network. We have made sure to build in support for all deployment scenarios.

Level 11

Hi Richard, yes the Flow Storage Database can be run on that machine.

Level 11

Upgrading to NTA 4.0 should drastically improve your performance. I am curious, do you do lots of CBQoS monitoring?

Level 16

How about running under NeverFail? Does it support replication?

Level 14

Our Juniper gear support/use sampled sflow not sampled jflow. Does this matter for NTA 4.0?

Level 14

RC2 is released and sampled slow feature is still not implemented.

Level 15

And it won't be for 4.0, we could not contain it. Will remove from the description above.

This is stil fairly high on the list for vNext (246275)

Level 15

Have you tried NTA 4.0 yet?

MVP
MVP

fcaron yes, we have been testing it since it opened.  Still lacks several features to make it more usable/valuable to us, but overall, we have not had any issues with RC2.

Level 15

Can you confirm that the performance issue that you reported above is improved by 4.0?

Also, any input on the missing features would help.

Thanks wluther

Level 15

The NTA 4.0 situation should be similar to v3.11, as far as sampled flow processing:

- sflow should work (sflow is by nature sampled)

- sampled jflow should work, but we know that we have some issues with some devices (e.g. JunOS versions) that export flows without specifying that it is being sampled (so NTA processes those flows as unsampled ones=wrong stats).

Whatever your case maybe, if you encounter an issue in this area, we need a pcap, because these are usually NTA "not understanding" how the routers is telling us whether the traffic is sampled or not.

You can contact me directly with pcaps.

We are actively working on this (the "What Are we Working" blog post will be revised shortly now that NTA 4.0 is released)

Level 15

🙂

The NTA 4.0 situation should be similar to v3.11, as far as sampled flow processing:

- sflow should work (sflow is by nature sampled)

- sampled jflow should work, but we know that we have some issues with some devices (e.g. JunOS versions) that export flows without specifying that it is being sampled (so NTA processes those flows as unsampled ones=wrong stats).

Whatever your case maybe, if you encounter an issue in this area, we need a pcap, because these are usually NTA "not understanding" how the routers is telling us whether the traffic is sampled or not.

You can contact me directly with pcaps.

We are actively working on this (the "What Are we Working" blog post will be revised shortly now that NTA 4.0 is released)

About the Author
Buiding things is what I do. From LEGO castles to Spec Homes onto Video Games and now IT Software for the Pro's. I spent 10 years in the Gaming industry working on titles like Mortal Kombat, Blitz, Thief, and Deus Ex. I am going to spend the next "x" years making awesome IT Software.