-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[exporter/clickhouse] Update default logs table schema #33611
Merged
dmitryax
merged 3 commits into
open-telemetry:main
from
SpencerTorres:update-logs-schema
Jun 19, 2024
Merged
Changes from 2 commits
Commits
Show all changes
3 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
27 changes: 27 additions & 0 deletions
27
.chloggen/clickhouseexporter_update_default_logs_table.yaml
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,27 @@ | ||
# Use this changelog template to create an entry for release notes. | ||
|
||
# One of 'breaking', 'deprecation', 'new_component', 'enhancement', 'bug_fix' | ||
change_type: enhancement | ||
|
||
# The name of the component, or a single word describing the area of concern, (e.g. filelogreceiver) | ||
component: clickhouseexporter | ||
|
||
# A brief description of the change. Surround your text with quotes ("") if it needs to start with a backtick (`). | ||
note: Updated the default logs table to a more optimized schema | ||
|
||
# Mandatory: One or more tracking issues related to the change. You can use the PR number here if no issue exists. | ||
issues: [33611] | ||
|
||
# (Optional) One or more lines of additional information to render under the primary note. | ||
# These lines will be padded with 2 spaces and then inserted directly into the document. | ||
# Use pipe (|) for multiline entries. | ||
subtext: Simplified data types, improved partitioning and time range queries. | ||
|
||
# If your change doesn't affect end users or the exported elements of any package, | ||
# you should instead start your pull request title with [chore] or use the "Skip Changelog" label. | ||
# Optional: The change log or logs in which this entry should be included. | ||
# e.g. '[user]' or '[user, api]' | ||
# Include 'user' if the change is relevant to end users. | ||
# Include 'api' if there is a change to a library API. | ||
# Default: '[user]' | ||
change_logs: [] |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
general LGTM. just wondering
ORDER BY (TimestampDate, TimestampTime)
may not better than ORDER BY ServiceName, SeverityText, toUnixTimestamp(Timestamp), beacause ServiceName and SeverityText( also as well-known logLevel) is the most common filter when query service log, can you write more text explain why remove them? thanks.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It can be difficult to model a decent table that works for everyone (consider issues like #32215)
The idea behind this change is to simply make time range queries work as best they can. Every log has a timestamp, but not always a proper
ServiceName
orSeverity*
. Some OTel data isn't composed very well.SeverityText
might not be as good asSeverityNumber
, and if we try to add all of these toORDER BY
then it starts to lose its purpose as a primary index.For those who will be using this exporter in production, the goal is to have them use this as a starting point, and then add the appropriate columns to the
ORDER BY
depending on their primary column. For example, look at how this blog post chooses to usePodName
andTimestamp
:What we've found is that a lot of these values are not necessary in the order by, especially ones after the
Timestamp*
columns (such asTraceId
in the current version). Most log queries are going to be in a tight range of time (5, 15, 30, 60 minutes) and these smallerORDER BY
clauses favor this. Again, you can always go a step further by adding your preferred column to the start of it, such asServiceName
,SeverityText
,PodName
, or some combination of these.The goal is to have a good default that is easy for others to expand on for their own deployment, while also still giving a good default for those who don't bother to configure one. If you're at the scale where this schema becomes a problem, you would already be using your own schema.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ServiceName is a required in spec. https://opentelemetry.io/docs/specs/semconv/resource/#service. to say the least, ServiceName is needed in order by columns. see also as #31670
in
PodName
blog case , i think most common usage query pattern isPodName like xxx%
, notPodName= xxx
, mostly query a workload log, not the specific pod log. actually, use a serviceName as workload name will be more reasonaly.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is reasonable enough since it is a default schema, and if someone needs to change it they're free to do so for their deployment.
As you suggested, I have added
ServiceName
to the default schema.