Search Server, or Elastic Search is a component that is leveraged by xFlow and Service Point to access content from Service Desk and Service Catalog. The following is a guide to how the Search Server component operates and what to look for in troubleshooting.
Release : 17.3
Component : SDM - xFlow
Logging for Search Server/ElasticSearch is contained in the ca_es_cluster.log log file, which is contained in the Search Server install directory's logs directory. Depending on the release, the default directory locations are:
rootLogger.level = info
rootLogger.level = DEBUGSave the "log4j2.properties" file, then recycle Search Service
When performing an initial load (pdm_es_initial_load.bat) or a subsequent index rebuild (pdm_es_rebuild_index.bat), file initial_load.log will be of value. This log file can be located in the C:\Program Files\CA\SC\CASearchServer\search\logs directory.
Within SDM, under pdm_status, there will be an entry for "es_ebl" or the "Search Deamon" process. Note that there is a cosmetic spelling error for "Deamon". The "es_ebl" process will connect to Search Server to pass on content from SDM.
How this works is when an entry in SDM is recorded that needs to be passed on to Search Server, the "es_ebl" process will write an entry to the backend database table "es_events", then a "Push" is done to write the content over to the appropriate index in Search Server. Once the push to Search Server is completed, the corresponding entry in the database table "es_events" is deleted. Normally, the "es_events" table is empty, unless there is data to be pushed over to ElasticSearch. Once it is pushed to SS, the "es_events" table entries is deleted.
Log file of interest is the esEvents.log in the SDM log directory. One should examine this log for troubleshooting concerns involving ticket data from SDM to be transferred across to Search Server. To turn up the logging, one must update the esLog4j.properties file in NX_ROOT\site\cfg to debug levels, then run "pdm_bounce es_ebl" to restart the SDM "Search Deamon" process.
Within Catalog, the interaction is simpler. Catalog will make a direct connection to the Search Server to push its contents over to the appropriate index stored in Search Server.
Log file of interest is the Catalog view.log. One should examine this log for troubleshooting concerns involving request data and offering data from Catalog to be transferred across to Search Server. There will be entries for the Search Server interactions if one searches for "ESClient". View.log would need to have debugging enabled to view the content.
xFlow and Service Point will utilise the Search Microservice defined in xFlow to interface and obtain materials from Search Server. One may consider turning up logging on the Search Microservice to view the content and materials that xFlow and Service Point obtains for a given transaction between its Search Microservice and the Search Server. Logs of interest will be the searchMS_debug.log and its derivative logs in the xFlow install directory.
The most common method to view the contents of Search Server's indexes is to utilise the Chrome plugin "ElasticSearch Head". A common activity is to use this functionalty to directly examine a given index stored in Search Server to determine its contents and accuracy when SDM or Catalog writes to the indexes and xFlow or Service Point reads from the indexes.
Information on the plugin is available here:
Once the plugin has been installed on your Chrome browser instance, you can access from this location:
Enter the specific Search Server address and click Connect. You can view and manipulate the indices that have been defined in Search Server:
Relevant KB Articles of interest:
Enable CA Service Catalog's TRACE (or DEBUG) level for diagnostic purposes
Turning on logging for xFlow
How to recreate indexes on CA Search Server?