Semarchy Monitoring and Health Check Best Practices

Owned by Former user (Deleted)
Last updated: Mar 14, 2018 by Marc Spica (Deactivated)
2 min read


This is a quick-reference guide outlining typical monitoring best practices for a Semarchy deployment. As with any monitoring effort, the ideal is to preemptively find problems before they effect a production environment.


Third-party infrastructure:

  • Semarchy HW and SW infrastructure
    • Hardware
      • Best practice is to setup agent/agentless monitoring for all involved hardware with thresholds on CPU usage, Memory usage and HD usage.
  • Operating Systems
    • While a simple ping may be a good start, there are several reasons why the OS might be primarily down, but would respond to a ping. For those reasons, it’s recommended to setup agent/agentless monitoring for all OS’s
  • Oracle RDBMS
    • It’s also recommended to monitor the DB for its performance and health. More information can be found here.
  • App server
    • The app server can easily be checked by scanning it’s logs for errors and seeing if it is listening on its configured ports. This is the primary place for issues with the Semarchy application to be logged. However, as a best practice it’s best to use an off-the-shelf agent/agentless monitoring solution for your specific application server.

Semarchy Application Server

  • Semarchy
    • Reach App Server and successfully login (This is a simple test that can tell you the app server is running, the DB is running and they can talk to each other).
  • Login successfully
    • This is one step beyond connectivity and ensures a proper level of configuration between the app server, DB and authentication provider.
  • Viewing golden record
    • This forces other queries into the DB.
  • Monitor Semarchy task staus
    • This can be monitored in the UI, via Admin Console -> Execution Engine Console. This will show both the status of the execution engine AND what is currently running and/or queued up.
    • In addition, the all jobs are logged in the database in “Repo_Schema”.MTA_JOB_LOG which can be directly queried for errors or suspensions. Here is a list of possible Job statuses : RUNNING, SUSPENDED, DONE, ERROR