![]() ![]() or the search used for the import has a too short timerange, that does not mach the metric collection interval.To address it, measure your average lag, and decide if you can improve or adjust the search windows to account for that lag.Or the data has lag, therefore is out of the search window.To address this you want to check the data ingestion and frequency (maybe send data more frequently).the host matching this entity is not sending data consistently.So the root cause for unstable entities may be : It looks for key metric "metric_name=Processor.* OR metric_name=processor.*"Īnd it runs every minute, and look back 90seconds. Tune the cron schedule of the recurring import searches to search less frequently in order to ensure your entity status updates on time.īy example for the Windows entities, the scheduled saved search doing the import is called "ITSI Import Objects - Perfmon" >Note:If you have a large number of entities, the recurring bulk import can take a longer time to complete. Out of the box, the ITSI entity import are very frequent and aggressive, this also may impact the detection It will flag it as "unstable" if the entity is not constantly detected, and "inactive" if this is constant. The logic to change the status of an entity if that when the scheduled import ran, it did no find data for that entity (for the health metric) in the timerange of the search. My understanding that you have entities detected in ITSI, in version 4.9.*Īnd some of those entities status are often flagged as "unstable" or "inactive" ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |