Central or Auto Cached Resources List Resources Updates

Hi all,

I’m sure many of you are aware of the resources list such as interfaces being cached once the node is created and when user does “Force refresh”, since discovery doesn’t really update the list, is there a way to have them automatically updated every two weeks for instance, without me having to visit every node and forcing that refresh? Maybe one place to update all? There are some nodes with resources that have not been refreshed in two years and those things change every now and then.

This is the cache I’m talking about: https://support.solarwinds.com/Success_Center/Orion_Platform/Knowledgebase_Articles/Cached_version_of_resources_during_List_Resources_in_Orion_Platform

Thank you!

Find more posts tagged with

force refresh

cache

interfaces

monitorin

resource list

Accepted answers

All comments

tigerr

Does anyone have any ideas?

joedissmeyer

(FYI - Article location has moved to here: Success Center )

This is something that I am working through as well. Figuring out how to force a new cache refresh every week (or even every month) would be ideal for my use case.

I'm browsing the database structure now, looking for where the cached resources are located....

joedissmeyer

Update:

I found the cached node resources in the `NodeListResourcesCache` table in the Orion database.

You can run this query to view the top 1000 cached entries:

```

SELECT TOP (1000) [NodeId]

,[CachedTime]

,[CacheBlob]

FROM [NodeListResourcesCache]

```

The cached resources for each node will display only if the cache data exists.

However you should know that clearing out this table does NOT force a cache refresh. From what I've been able to determine, there are only two ways to force a cache refresh for a node's resources:

Run a Network Discovery Job.
Under Managed Nodes or Node Details view click "List Resources" for the node. And if a cached version displays click "Force Refresh". See special note below...

** Special note: After clicking List Resources, a new cached resource entry for the node will NOT be committed to the database unless you click SUBMIT button.
If you click CANCEL the cache refresh won't commit to the database. You MUST click SUBMIT even if you don't make any changes.

So one solution to this might be to just run scheduled discovery jobs to force the cache to get refreshed on a regular basis. This is probably what needs to happen anyways to just get new cached resources for monitored nodes.

But for our use case, where we are trying to see if caches resources are not updating because of a possible polling issue then we need to run regular reports to find what nodes aren't getting new cached resources.

To do this, build a custom SQL report to query the `NodeListResourcesCache`. The SQL query will look something like this:

```

-- Display all cached node resources older than 15 days

SELECT

NodeId,

CachedTime,

CacheBlob

FROM

[NodeListResourcesCache]

WHERE

CachedTime < DATEADD(DAY,-15,getdate())

```

And if you want to pull in the Node caption as well, then your SQL query will look like this:

```

-- Display all cached node resources older than 15 days, include node caption.

SELECT

NLRC.NodeId,

N.Caption,

NLRC.CachedTime,

NLRC.CacheBlob

FROM

[NodeListResourcesCache] NLRC

JOIN [Nodes] N ON NLRC.NodeId = N.NodeID

WHERE

CachedTime < DATEADD(DAY,-15,getdate())

ORDER BY N.Caption ASC

```

Modify as you see fit.

- Joey D

tigerr

Does network discovery disrupt operations? When it runs will it cause things to go grey or red? I never ran it because I have a huge network and I do not want things to go badly while running network discovery.

joedissmeyer

tigerr I'll try to respond as best I can. Also keep in mind that discovery jobs are things are a matter of semantics amogst IT Pros So there is a large variety of opinion on this topic. I'm just giving my own opinion here based on my experience.

Q. Does network discovery 'disrupt' operations? When it runs will it cause things to go grey or red?

A. Well... I suppose it all depends on how you configure your discovery jobs. If you have some small-sized discovery jobs then you have nothing to worry about. But if you have some very large jobs where you are scanning thousands of IPs across hundreds of subnets, then more planning is needed.

---

Over the years I have come up with my own way of rating and planning discovery jobs borrowing some of these details from official documentation as well as from the Thwack users here. Some good general information can be found here: Advanced discovery in the Orion Platform .

There are small discovery jobs, medium-sized discovery jobs, and then there are very large discovery jobs. Of course it would be wise to schedule jobs during a planned maintenance time period or a time where monitoring/polling and the business wouldn't be impacted (i.e. non-business hours or overnight) but it is all up to you on how you want to do it.

For example, if you have a job to scan a /24 subnet using WMI or SNMP, and the job timeout is set to 30 minutes then this would be considered a small discovery job. A small discovery job would have the least likely impact to any existing monitoring in place and wouldn't cause increased stress on a polling engine with resources to spare. With small jobs as long as your polling engine(s) are not close to their max polling capacity they can handle the increased short-term load. Therefore I would expect a small discovery job's impact to polling would be non-existent. Personally I run small jobs during the business day, including sometimes on-demand, with zero impact to existing monitoring and polling (no false alerts, no missed polling intervals, etc.). Also, I have many small discovery jobs that run on a daily basis instead of being scheduled weekly.

Next up would be a medium-sized job. This would be a WMI/SNMP scan for "decent-sized" subnets (maybe up to around 500-750 hosts/ips) with at least a 1 hour timeout. Because these are scanning much larger host ranges it would be best to run during off-hours and on a weekly basis. So unless your network is incredibly dynamic and needs to be up-to-date quickly it is best to NOT run medium-sized discovery jobs on a daily basis. I have a few medium-sized jobs that run in the very early morning (2am, 3am) as to not cause an impact to existing polling. But I do run my medium-sized jobs daily because my environment is highly dynamic and needs to be up-to-date as soon as possible. Getting updated discovery data on a daily basis is a good enough trade-off for my situation. I would prefer to run weekly on Sundays at 3am but.... hey, it is what it is. You play the cards you are dealt.

Every once in a while one of my medium-sized discovery jobs never finishes and hits the timeout. This is a job that can scan up to 750 hosts using WMI (Windows servers) including the need to discover applications with SAM with a 1 hour timeout. When the timeout hits the job status says "Not completed". This is an indicator that you need to split that discovery job into multiple smaller jobs, spread out over time. So what I'll do is take that job, split it into 3 smaller jobs with a 30 minute timeout each where each job does NOT overlap, and I schedule them back-to-back. So job #1 will run at 2am, then job #2 at 2:30am, and so on.

I prefer to do this instead of just increasing the 1 hour timeout for the larger single job as this allows for me to better control the job.

Finally, there are very large discovery jobs for 1,000 or more hosts at a time. These are typically discovery jobs that you would run for the first time on a new install of Solarwinds NPM or SAM, or are large jobs that would run on a weekly basis that might take longer than an hour (or several hours) to complete. It is possible for very large discovery jobs to negatively impact polling engine performance and cause false alerts and cause existing polling to fall behind. So for these types of jobs a lot of planning and tuning is needed. Personally I don't run large discovery jobs because I can't wait a week for current data but many others don't have this problem at all because they have done their homework.

I hope this info helps you out!

- Joey D

tigerr

Thank you, Joey, for taking the time to explain!