OpenCRVS
v1.3
v1.3
  • 👋Introduction
  • Product Specifications
    • Functional Architecture
    • Workflow management
    • Status Flow Diagram
    • Users
      • Examples
    • Core functions
      • 1. Notify event
      • 2. Declare event
      • 3. Validate event
      • 4. Register event
      • 5. Print certificate
      • 5. Issue certificate
      • 6. Search for a record
      • 7. View record
      • 8. Correct record
      • 9. Verify record
      • 10. Archive record
      • 11. Vital statistics export
    • Support functions
      • 10. Login
      • 11. Audit
      • 12. Deduplication
      • 13. Performance management
      • 14. Payment
      • 15. Learning
      • 16. User support
    • Admin functions
      • 17. User management
      • 18. Comms management
      • 19. Content management
      • 20. Config management
    • Data functions
      • 21. Legacy data import
      • 22. Legacy paper import
  • Technology
    • Architecture
      • Performance tests
    • Standards
      • FHIR Documents
        • Event Composition
        • Person
        • Registration Task
        • Event Observations
        • Locations
    • Security
    • Interoperability
      • Create a client
      • Authenticate a client
      • Event Notification clients
      • Record Search clients
      • Webhook clients
      • National ID client
      • FHIR Location REST API
      • Other ways to interoperate
  • Default configuration
    • Intro to Farajaland
    • Civil registration in Farajaland
    • OpenCRVS configuration in Farajaland
      • User / role mapping
      • Application settings
      • Declaration forms
      • Certificate templates
    • Business process flows in Farajaland
  • Setup
    • 1. Establish team
    • 2. Gather requirements
    • 3. Installation
      • 3.1 Set-up a local development environment
        • 3.1.1 Install the required dependencies
        • 3.1.2 Install OpenCRVS locally
        • 3.1.3 Starting and stopping OpenCRVS
        • 3.1.4 Log in to OpenCRVS locally
        • 3.1.5 Tooling
      • 3.2 Set-up your own country configuration
        • 3.2.1 Fork your own country configuration repository
        • 3.2.2 Set up administrative address divisions
          • 3.2.2.1 Prepare source file for administrative structure
          • 3.2.2.2 Prepare source file for statistics
        • 3.2.3 Set up CR offices and Health facilities
          • 3.2.3.1 Prepare source file for CRVS Office facilities
          • 3.2.3.2 Prepare source file for health facilities
        • 3.2.4 Set up employees & roles for testing or production
          • 3.2.3.1 Prepare source file for employees
          • 3.2.3.2 Configure role titles
        • 3.2.5 Set up application settings
          • 3.2.5.1 Configuring Metabase Dashboards
        • 3.2.6 Configure certificate templates
        • 3.2.7 Configure declaration forms
          • 3.2.7.1 Configuring an event form
        • 3.2.8 Seeding your local development environment database
          • 3.2.8.1 Clearing your local development environment database
        • 3.2.9 Countryconfig APIs explained
          • 3.2.9.1 Managing language content
      • 3.3 Set-up a server-hosted environment
        • 3.3.1 Provision your server nodes with SSH access
        • 3.3.2 Provision environment
        • 3.3.3 Provision a comms gateway
        • 3.3.4 Set up an SMTP server for OpenCRVS monitoring alerts
        • 3.3.5 Setup DNS A records
        • 3.3.6 Deploy (Automated & Manual)
        • 3.3.7 Seeding & clearing data on a server
        • 3.3.8 Automated & manual backup and manual restore
    • 4. Functional configuration
      • 4.1 Configure application settings
      • 4.2 Configure registration periods and fees
      • 4.3 Create new user roles
      • 4.4 Managing system users
    • 5. Testing
    • 6. Go-live
    • 7. Monitoring
      • 7.1 Application logs
      • 7.2 Infrastructure health
      • 7.3 Routine monitoring checklist
      • 7.4 Setting up alerts
      • 7.5 Managing a Docker Swarm
  • General
    • Contributing
    • Releases
      • v1.3.5: Release notes
      • v1.3.4: Release notes
      • v1.3.2: Release notes
      • v1.3.1: Release notes
      • v1.3.* to v1.3.* Migration notes
      • v1.3.0: Release notes
      • v1.2.* to v1.3.* Migration notes
        • v1.2 to v1.3: Form migration
      • v1.2.1: Release notes
      • Patch: Elasticsearch 7.10.2
      • v1.2.0: Release notes
      • v1.1.* to v1.2.* Migration notes
      • v.1.1.2: Release notes
      • v.1.1.1: Release notes
      • v1.1.0: Release notes
    • Interoperability roadmap
    • Product roadmap
Powered by GitBook
On this page
  • Searching the logs
  • Tracing a request through different services
  • Traces
  1. Setup
  2. 7. Monitoring

7.1 Application logs

Previous7. MonitoringNext7.2 Infrastructure health

Last updated 1 year ago

All services in the OpenCRVS architecture emit logs that can be observed in real-time. The most common use case for viewing logs is debugging an issue with the installation. The logs from each service are collected automatically by Docker Swarm and sent to Kibana for developers and maintainers to easily access. The items include information about HTTP requests and responses, informational logging (e.g. auth service sending a verification SMS) and errors that have happened as part of requests.

Application logs

To access the logs of a specific service, first, log in to Kibana and navigate to Observability -> APM, open up the service you want to observe and navigate to the Logs - tab. In this view, you see the complete standard output of the microservice. You can also search log items by providing a time range.

Searching the logs

Log stream

Tracing a request through different services

In the log stream view, you can see that all log items related to HTTP requests contain a header field called elastic-apm-traceparent.

"headers": {
  "elastic-apm-traceparent": "00-6be341213d9b92b6220d3f1b2eacbe84-d1ff19cd4225d9d2-01",

This field is extremely useful for getting an understanding of everything that happened during the request's lifecycle. The second part of the id, 6be341213d9b92b6220d3f1b2eacbe84, be used for searching all requests related to this transaction.

Traces

Another way of finding a specific request is by finding it through the Observability -> APM -> Traces view.

In this view, you can see all requests that happened in the selected time interval grouped by the type of the request. By clicking on the request type you are interested in observing, you can see for example the average timings and error rates for that request type. At the bottom of the page, you also see trace samples of all of the actual requests made during the specified time interval.

This is especially useful for figuring out in which service the request fails or for detecting bottlenecks in the architecture. By clicking on Investigate -> Trace logs you can navigate back to the logs view to see all logs corresponding to the selected request.

Read more:

By navigating to Observability -> Logs -> Stream, you see all logs of all applications in real time. This view also lets you search for specific events happening in the stack during a specified time range and search terms like the request URL, header value or other values in the request or in the response object. More information about this view can be read .

here
How to easily correlate logs and APM traces for better observability
Tail log files