sentry-instrument-logging

Name: sentry-instrument-logging
Author: getsentry

242stars30forks

How to install sentry-instrument-logging?

getsentry/sentry-for-ai/sentry-instrument-logging

$npx -y skills add getsentry/sentry-for-ai --skill sentry-instrument-logging

Installs into the current project.

Summary

Instruments structured Sentry logs in a new or existing application.

Files · 1

View on GitHub

SKILL.md

1	# Instrument Sentry Logging
2
3	This skill adds structured Sentry logs to an application following the guidance
4	in [Instrumentation guidance](#instrumentation-guidance).
5
6	The goal is to provide a small set of high-value log messages that make
7	production behavior easier to understand and debug.
8
9	The log messages added by this skill should also serve as clear, repeatable,
10	examples that users can follow when instrumenting the rest of their application.
11
12	## Prerequisites
13
14	The repository should already have basic Sentry configuration.
15
16	If Sentry has not yet been configured, offer to set it up using the appropriate
17	[skills](./).
18
19	## Steps
20
21	1. Inventory every application in the repository. Locate language/runtime
22	manifests (`composer.json`, `package.json`, `go.mod`, `Gemfile`,
23	`pyproject.toml`, `Cargo.toml`, …). Each manifest typically marks a
24	separately deployed application. Produce an explicit table and treat it as
25	the work list for the rest of this skill:
26
27	\| App \| Path \| Language \| Sentry SDK? \| Logging abstraction \| Status \|
28	\|-----\|------\|----------\|-------------\|---------------------\|--------\|
29
30	If the repo has more than ~2 apps, confirm scope with the user before
31	starting: which apps to instrument now, and at what depth.
32
33	2. Establish shared conventions once, up front — before touching any app.
34	Decide on consistent attribute namespacing (e.g. `myapp.<domain>.<field>`),
35	event-name phrasing, and log levels, so logs from every language can be
36	searched and correlated together. Record these so each per-app pass follows
37	them. Note service boundaries that propagate trace headers
38	(baggage / sentry-trace) — logs on both sides of such a call should share
39	attribute names so a single trace reads coherently across languages.
40
41	3. **For each application in the inventory, complete the full pass below before
42	moving to the next**, updating its Status as you go
43	(`not started → configured → instrumented → verified`):
44
45	a. Read the corresponding language-specific skill in [skills](../) and
46	confirm Sentry logging is configured.
47	b. Determine the app's logging abstraction (Monolog/PHP, slog/Go,
48	Rails logger/Ruby, Pino or console/JS). If Sentry supports it, configure
49	that integration; otherwise use Sentry's logging SDK directly.
50	c. Identify a small number of high-value log messages, prioritizing runtime
51	decisions, important algorithms, audit events, and context around
52	recoverable failures. Follow
53	[Valuable log entries to instrument](#valuable-log-entries-to-instrument).
54	d. Add structured logs following the shared conventions from Step 2 and the
55	[Instrumentation guidance](#instrumentation-guidance).
56	e. Verify: run the app's lint/type/test tooling if available, and confirm
57	logs are emitted. If the toolchain isn't available locally,
58	say so explicitly rather than implying it passed.
59
60	4. Apply a high-value log validation check. Review every added or modified log line
61	and remove or revise any log that does not pass this check:
62
63	\| Check \| Question \|
64	\|-------\|----------\|
65	\| Production question \| What concrete production question does this log answer? \|
66	\| Signal \| Would this still be useful if emitted hundreds or thousands of times? \|
67	\| Telemetry fit \| Is this better represented as a trace, metric, or Sentry error? \|
68	\| Existing coverage \| Is this already captured by an exception, existing log, or shared API/client wrapper? \|
69	\| Structure \| Are event names and attributes consistent with the shared conventions? \|
70	\| Safety \| Does it avoid PII, secrets, raw payloads, and unstable exception messages? \|
71	\| Actionability \| Would seeing this log change how someone investigates or responds? \|
72
73	Prefer removing logs that merely confirm routine UI interactions, duplicate
74	generic API failures, or record expected validation failures without adding
75	meaningful context.
76
77	Keep logs that explain important runtime decisions, summarize multi-step
78	workflows, record important audit/business events, or provide context around
79	recoverable failures.
80
81	For each remaining log, be able to write a one-sentence justification:
82	"This log is valuable because it helps answer <specific question>."
83
84	5. Reconcile against the inventory. Confirm every in-scope app reached
85	`verified` (or was explicitly deferred). Report per-app status so partial
86	coverage is never mistaken for full coverage.
87
88	## Instrumentation guidance
89
90	### When to reach for logging, vs., other types of telemetry
91
92	Logs are ideal for recording the context and decisions that explain what
93	happened during an application's execution.
94
95	- For measuring the performance and flow of requests, use tracing.
96	- For unexpected

People who liked this also viewed

6 picks

Type

entra-app-registrationGuides Microsoft Entra ID app registration, OAuth 2.0 authentication, and MSAL integration. USE FOR: create app registration, register Azure AD app, configure OAuth, set up authentication, add API perSkillsJul 2026471k1.3k
azure-complianceRun Azure compliance and security audits with azqr plus Key Vault expiration checks. Covers best-practice assessment, resource review, policy/compliance validation, and security posture checks. WHEN: SkillsJul 2026470k1.3k
azure-rbacOfficial agent plugin providing skills and MCP server configurations for Azure scenarios.SkillsJul 2026466k1.3k
better-auth-best-practicesAgent skill from better-auth/skillsSkillsJul 202678k203
firebase-security-rules-auditorA skill to evaluate how secure Firestore security rules are. Use this when Firestore security rules are updated to ensure that the generated rules are extremely secure and robust.SkillsJul 202676k386
audit-websiteAudit a website with the squirrelscan CLI and fix the findings in code. Runs SEO, performance, security, technical, content, accessibility, and 15 other rule categories (260+ rules), returns an LLM-opSkillsJul 202665k85

sentry-instrument-logging

242stars30forks

View on GitHub

How to install sentry-instrument-logging?

getsentry/sentry-for-ai/sentry-instrument-logging

$npx -y skills add getsentry/sentry-for-ai --skill sentry-instrument-logging

Installs into the current project.

Summary

Instruments structured Sentry logs in a new or existing application.

Files · 1

View on GitHub

SKILL.md

1	# Instrument Sentry Logging
2
3	This skill adds structured Sentry logs to an application following the guidance
4	in [Instrumentation guidance](#instrumentation-guidance).
5
6	The goal is to provide a small set of high-value log messages that make
7	production behavior easier to understand and debug.
8
9	The log messages added by this skill should also serve as clear, repeatable,
10	examples that users can follow when instrumenting the rest of their application.
11
12	## Prerequisites
13
14	The repository should already have basic Sentry configuration.
15
16	If Sentry has not yet been configured, offer to set it up using the appropriate
17	[skills](./).
18
19	## Steps
20
21	1. Inventory every application in the repository. Locate language/runtime
22	manifests (`composer.json`, `package.json`, `go.mod`, `Gemfile`,
23	`pyproject.toml`, `Cargo.toml`, …). Each manifest typically marks a
24	separately deployed application. Produce an explicit table and treat it as
25	the work list for the rest of this skill:
26
27	\| App \| Path \| Language \| Sentry SDK? \| Logging abstraction \| Status \|
28	\|-----\|------\|----------\|-------------\|---------------------\|--------\|
29
30	If the repo has more than ~2 apps, confirm scope with the user before
31	starting: which apps to instrument now, and at what depth.
32
33	2. Establish shared conventions once, up front — before touching any app.
34	Decide on consistent attribute namespacing (e.g. `myapp.<domain>.<field>`),
35	event-name phrasing, and log levels, so logs from every language can be
36	searched and correlated together. Record these so each per-app pass follows
37	them. Note service boundaries that propagate trace headers
38	(baggage / sentry-trace) — logs on both sides of such a call should share
39	attribute names so a single trace reads coherently across languages.
40
41	3. **For each application in the inventory, complete the full pass below before
42	moving to the next**, updating its Status as you go
43	(`not started → configured → instrumented → verified`):
44
45	a. Read the corresponding language-specific skill in [skills](../) and
46	confirm Sentry logging is configured.
47	b. Determine the app's logging abstraction (Monolog/PHP, slog/Go,
48	Rails logger/Ruby, Pino or console/JS). If Sentry supports it, configure
49	that integration; otherwise use Sentry's logging SDK directly.
50	c. Identify a small number of high-value log messages, prioritizing runtime
51	decisions, important algorithms, audit events, and context around
52	recoverable failures. Follow
53	[Valuable log entries to instrument](#valuable-log-entries-to-instrument).
54	d. Add structured logs following the shared conventions from Step 2 and the
55	[Instrumentation guidance](#instrumentation-guidance).
56	e. Verify: run the app's lint/type/test tooling if available, and confirm
57	logs are emitted. If the toolchain isn't available locally,
58	say so explicitly rather than implying it passed.
59
60	4. Apply a high-value log validation check. Review every added or modified log line
61	and remove or revise any log that does not pass this check:
62
63	\| Check \| Question \|
64	\|-------\|----------\|
65	\| Production question \| What concrete production question does this log answer? \|
66	\| Signal \| Would this still be useful if emitted hundreds or thousands of times? \|
67	\| Telemetry fit \| Is this better represented as a trace, metric, or Sentry error? \|
68	\| Existing coverage \| Is this already captured by an exception, existing log, or shared API/client wrapper? \|
69	\| Structure \| Are event names and attributes consistent with the shared conventions? \|
70	\| Safety \| Does it avoid PII, secrets, raw payloads, and unstable exception messages? \|
71	\| Actionability \| Would seeing this log change how someone investigates or responds? \|
72
73	Prefer removing logs that merely confirm routine UI interactions, duplicate
74	generic API failures, or record expected validation failures without adding
75	meaningful context.
76
77	Keep logs that explain important runtime decisions, summarize multi-step
78	workflows, record important audit/business events, or provide context around
79	recoverable failures.
80
81	For each remaining log, be able to write a one-sentence justification:
82	"This log is valuable because it helps answer <specific question>."
83
84	5. Reconcile against the inventory. Confirm every in-scope app reached
85	`verified` (or was explicitly deferred). Report per-app status so partial
86	coverage is never mistaken for full coverage.
87
88	## Instrumentation guidance
89
90	### When to reach for logging, vs., other types of telemetry
91
92	Logs are ideal for recording the context and decisions that explain what
93	happened during an application's execution.
94
95	- For measuring the performance and flow of requests, use tracing.
96	- For unexpected

People who liked this also viewed

6 picks

Type