Which version of EventSentry are you currently on?
Are you utilizing the collector component/service?
In your EventSentry settings, when you select the database action (on the left side you can scroll to the Actions section and then select the database) and view the database settings on the right, is the "Ignore binary data" checkbox turned on? If the binary data is not being ignored, and your database is quite large, the write performance of new events might be so bad that you might end up with a constant backlog of events that are waiting for 1 day or more, and a backlog of that size is not something that the agent is designed to deal with for an extended amount of time such as having a 1-day event backlog (or more) for multiple days in a row. The binary data setting/function is explained more here: https://www.eventsentry.com/kb/347
If your EventSentry installation is healthy and relatively up to date and this just a problem with certain machines, you can use the agent database status utility to get a list of machines that haven't sent in any events recently:
https://www.eventsentry.com/documentation/help/html/?agent_database_status_utility.htm
The first example command on that page would be the syntax for the type of reporting you'd want, i.e. to check the Event Log data for any missing machines and provide a list of machines that haven't sent in any Event Log data in the past 30 minutes.
If you set this up as an Embedded Script in EventSentry, and then make a System Health package that's assigned to the EventSentry server (not assigned to additional machines since they'd all be bogging down the database with the same search at the same time) you can add an Application Scheduler item to your new System Health package and add a schedule your new embedded script. The schedule you set up should have some relation to the time value in your script, i.e. if your script is checking for machines that haven't sent in any Event Log data in the past 30 minutes it doesn't do much good to check the result every minute or to only check the result once per day, it'd be a good idea to choose a recurring schedule of every 30 minutes or every 60 minutes in this example. The default alert settings would notify you when your script finds agents that haven't sent in Event Log data recently (the script finding any results is an "Error" by default and "Error" events are emailed by default) but you might need to click the Alerts button at the bottom right corner of the Application Scheduler settings and set up a custom filter/alert to notify you when your script produces an error and has detected that one or more agents haven't sent in Event Log data recently.
In your EventSentry settings, when you select the database action (on the left side you can scroll to the Actions section and then select the database) and view the database settings on the right, is the "Ignore binary data" checkbox turned on? If the binary data is not being ignored, and your database is quite large, the write performance of new events might be so bad that you might end up with a constant backlog of events that are waiting for 1 day or more, and a backlog of that size is not something that the agent is designed to deal with for an extended amount of time such as having a 1-day event backlog (or more) for multiple days in a row. The binary data setting/function is explained more here: https://www.eventsentry.com/kb/347
If your EventSentry installation is healthy and relatively up to date and this just a problem with certain machines, you can use the agent database status utility to get a list of machines that haven't sent in any events recently:
https://www.eventsentry.com/documentation/help/html/?agent_database_status_utility.htm
The first example command on that page would be the syntax for the type of reporting you'd want, i.e. to check the Event Log data for any missing machines and provide a list of machines that haven't sent in any Event Log data in the past 30 minutes.
If you set this up as an Embedded Script in EventSentry, and then make a System Health package that's assigned to the EventSentry server (not assigned to additional machines since they'd all be bogging down the database with the same search at the same time) you can add an Application Scheduler item to your new System Health package and add a schedule your new embedded script. The schedule you set up should have some relation to the time value in your script, i.e. if your script is checking for machines that haven't sent in any Event Log data in the past 30 minutes it doesn't do much good to check the result every minute or to only check the result once per day, it'd be a good idea to choose a recurring schedule of every 30 minutes or every 60 minutes in this example. The default alert settings would notify you when your script finds agents that haven't sent in Event Log data recently (the script finding any results is an "Error" by default and "Error" events are emailed by default) but you might need to click the Alerts button at the bottom right corner of the Application Scheduler settings and set up a custom filter/alert to notify you when your script produces an error and has detected that one or more agents haven't sent in Event Log data recently.
In addition to the above:
If the issues are happening on the EventSentry server, consider using Task Scheduler to restart the EventSentry service every few days.
Also consider good housekeeping:
Restarting workstations every few days is a good idea, and restarting Servers every 14 days, or 7 days if they are an older version of windows. Restarting machines is part of a good maintenance schedule anyway.
Servers can run for months without issue, but if the Server does multiple functions, they can get lethargic, particularly around memory use and allocation. It all depends on the software applications and services that are installed and running.
The risk of workstations hardware errors rises exponentially past a certain number of days on.
Ingmar Koecher
Is there away to get notified if an agent/computer is not reporting events to the consolidation server. Seen cases where agent seemed ok, but not events logged for days.