Skip to content

Commit 5b48391

Browse files
authored
Add Observe example
1 parent a543ec5 commit 5b48391

File tree

1 file changed

+91
-1
lines changed

1 file changed

+91
-1
lines changed

README.md

Lines changed: 91 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -3,12 +3,91 @@
33

44
Rails Semantic Logger replaces the Rails default logger with [Semantic Logger](https://logger.rocketjob.io/)
55

6+
When any large Rails application is deployed to production one of the first steps is to move to centralized logging, so that logs can be viewed and searched from a central location.
7+
8+
Centralized logging quickly falls apart when trying to consume the current human readable log files:
9+
- Log entries often span multiple lines, resulting in unrelated log lines in the centralized logging system. For example, stack traces.
10+
- Complex Regular Expressions are needed to parse the text lines and make them machine readable. For example to build queries, or alerts that are looking for specific elements in the message.
11+
- Writing searches, alerts, or dashboards based on text logs is incredibly brittle, since a small change to the text logged can often break the parsing of those logs.
12+
- Every log entry often has a completely different format, making it difficult to make consistent searches against the data.
13+
14+
For these and many other reasons switching to structured logging, or logs in JSON format, in testing and production makes centralized logging incredibly powerful.
15+
16+
For example, adding these lines to `config/application.rb` and removing any other log overrides from other environments, will switch automatically to structured logging when running inside Kubernetes:
17+
~~~ruby
18+
# Setup structured logging
19+
config.semantic_logger.application = "my_application"
20+
config.semantic_logger.environment = ENV["STACK_NAME"] || Rails.env
21+
22+
# Switch to JSON Logging output to stdout when running on Kubernetes
23+
if ENV["LOG_TO_CONSOLE"] || ENV["KUBERNETES_SERVICE_HOST"]
24+
config.rails_semantic_logger.add_file_appender = false
25+
config.semantic_logger.add_appender(io: $stdout, level: ENV["LOG_LEVEL"] || config.log_level, formatter: :json)
26+
end
27+
~~~
28+
29+
Then configure the centralized logging system to tell it that the data is in JSON format, so that it will parse it for you into a hierarchy.
30+
31+
For example, the following will instruct [Observe](https://www.observeinc.com/) to parse the JSON data and create machine readable data from it:
32+
~~~ruby
33+
interface "log", "log":log
34+
35+
make_col event:parse_json(log)
36+
37+
make_col
38+
time:parse_isotime(event.timestamp),
39+
duration:duration_ms(event.duration_ms),
40+
level:string(event.level),
41+
name:string(event.name),
42+
message:string(event.message),
43+
metric:string(event.metric),
44+
named_tags:event.named_tags,
45+
payload:event.payload,
46+
tags:array(event.tags),
47+
host:string(event.host),
48+
application:string(event.application),
49+
environment:string(event.environment),
50+
level_index:int64(event.level_index),
51+
pid:int64(event.pid),
52+
thread:string(event.thread),
53+
file:string(event.file),
54+
line:int64(event.line),
55+
backtrace:array(event.backtrace),
56+
metric_amount:int64(event.metric_amount),
57+
dimensions:event.dimensions,
58+
exception:event.exception
59+
~~~
60+
61+
Now queries can be built to drill down into each of these fields, including `payload` which is a nested object.
62+
63+
For example to find all failed Sidekiq job calls where the causing exception class name is `NoMethodError`:
64+
~~~ruby
65+
filter environment = "uat2"
66+
filter level = "error"
67+
filter metric ~ /Sidekiq/
68+
filter (string(exception.cause.name) = "NoMethodError")
69+
~~~
70+
71+
Or, to create a dashboard showing the duration of all successful Sidekiq jobs:
72+
~~~ruby
73+
filter environment = "production"
74+
filter level = "info"
75+
filter metric ~ /Sidekiq.*/
76+
timechart duration:avg(duration), group_by(name)
77+
~~~
78+
679
* http://github.com/reidmorrison/rails_semantic_logger
780

881
## Documentation
982

1083
For complete documentation see: https://logger.rocketjob.io/rails
1184

85+
## Upgrading to Semantic Logger v4.15 - Sidekiq Support
86+
87+
Rails Semantic Logger introduces direct support for Sidekiq v4, v5, v6, and v7.
88+
Please remove any previous custom patches or configurations to make Sidekiq work with Semantic Logger.
89+
To see the complete list of patches being made, and to contribute your own changes, see: [Sidekiq Patches](https://github.com/reidmorrison/rails_semantic_logger/blob/master/lib/rails_semantic_logger/extensions/sidekiq/sidekiq.rb)
90+
1291
## Upgrading to Semantic Logger v4.4
1392

1493
With some forking frameworks it is necessary to call `reopen` after the fork. With v4.4 the
@@ -19,7 +98,18 @@ I.e. Please remove the following line if being called anywhere:
1998
SemanticLogger::Processor.instance.instance_variable_set(:@queue, Queue.new)
2099
~~~
21100

22-
## Supports
101+
## New Versions of Rails, etc.
102+
103+
The primary purpose of the Rails Semantic Logger gem is to patch other gems, primarily Rails, to make them support structured logging though Semantic Logger.
104+
105+
When new versions of Rails and other gems are published they often make changes to the internals, so the existing patches stop working.
106+
107+
Rails Semantic Logger survives only when someone in the community upgrades to a newer Rails or other supported libraries, runs into problems,
108+
and then contributes the fix back to the community by means of a pull request.
109+
110+
Additionally, when new popular gems come out, we rely only the community to supply the necessary patches in Rails Semantic Logger to make those gems support structured logging.
111+
112+
## Supported Platforms
23113

24114
For the complete list of supported Ruby and Rails versions, see the [Testing file](https://github.com/reidmorrison/rails_semantic_logger/blob/master/.github/workflows/ci.yml).
25115

0 commit comments

Comments
 (0)