Hosting and maintenance / observability web application logs
Observability and logbooks
Linked information about the application and its services to investigate errors and slowdowns with a relevant context.
Context for errors and slowdowns beyond simple availability
We correlate the application's events with domestic services and resource consumption for projects administered at SIDECUBE. Observability helps to investigate; availability verification has a separate role.
- Events chosenWe determine which errors and operations must be recorded, avoiding the unintended collection of data.
- Links between componentsWe follow the context of an operation between application, background processes and dependent services, where the training allows.
- Access and storageWe limit access to the logs and define the retention period. Passwords, tokens and sensitive data do not occur in diagnostic messages.
- Investigation alertsWe choose events that require attention and link the notification of concrete analytical steps.
What the service can include
The tools, storage of logs and interventions shall be sized separately. Useful logs do not guarantee immediate identification of any cause.
Diaries that help to reproduce a problem
- We're trying to record a representative event.
- We are checking the context, access and information collected.
- We confirm notifications for selected events.
- We document what is being followed and what remains out of the coverage.
Recommended pages
Pages related to this type of service: technologies, fields of activity, guides and complementary services.
Frequently Asked Questions
Before we begin the project
Choice, stages and support for Observability and Logs.
01 / Service
Purpose and conditions
Is the observability the same as monitoring availability?
No. Availability shows whether a service responds; logs and other indicators help to understand errors and internal behaviour.
Do they keep all the data in the logs?
No. We choose the information needed for the investigation and limit access and preservation. We avoid recording passwords, tokens and sensitive data.
02 / Preparation
take-over and access
How can an existing project be taken over?
We evaluate the platform, data and integration, then clarify compatibility, remedies and migration to SIDECUBE infrastructure. An initial audit can be delivered prior to the takeover decision; the full recurrent administration is done in our environment.
What information is needed for the estimation?
Platform and services used, data volume, important operations and known problems. We determine the works, access and responsibilities prior to intervention; passwords are not sent via public forms.
03 / Verification
Validation and limits
How do you check the result?
We're trying to record a representative event. We are checking the context, access and information collected. We confirm notifications for selected events. We document what is being followed and what remains out of the coverage.
What conditions and costs need to be clarified?
The tools, storage of logs and interventions shall be sized separately. Useful logs do not guarantee immediate identification of any cause.