Integrations / Observability
AWS CloudWatch Logs
Jigward reads your runtime logs the way a colleague with read access would, and only the ones you allow.
What Jigward can do in AWS CloudWatch Logs
-
Search logs in a time window
Within the log groups the connection allows, preferring the cheaper search to a query.
-
Run a bounded Logs Insights query
Bounded per run and per organization each day, and one at a time per account.
-
Say what came from the logs
Its answer says which facts the lines showed, and what they did not.
-
Keep what it read
The redacted lines go on the Task as a file members can download, with each read's groups, window and query.
-
Look where you point it first
An admin may bind log groups to a repository, so a Task on it looks there first.
How teams use it
-
Ask what the logs say
In a private Chat or a Task, describe what went wrong and when. Jigward picks the log groups that matter and reads a narrow window.
For example: Nobody could book a ride to Moon Base 2 from about 3 a.m. Anything in the logs?
-
Follow a browser bug into the logs
A browser session keeps each request's id, so a bug seen on the page can be traced into the logs of the service that answered it.
What you need
- An AWS account whose logs you want Jigward to read, and permission there to create a CloudFormation stack with an IAM role.
- A Jigward organization, and an admin in it to connect the account.
Connecting it
- An admin gives the account's id, the regions its logs live in, and one to three log group name prefixes.
- Open the link Jigward gives while signed in to AWS, and create the stack. It makes one role.
- Check the connection in Jigward. It shows as connected, waiting for its role, or unreachable with why.
Security and access
| Permission | Access | Why Jigward needs it |
|---|---|---|
| logs:DescribeLogGroups | Read | To list the log groups it may read. |
| logs:FilterLogEventslogs:DescribeLogStreams | Read | To search log events, only under the prefixes you named. |
| logs:StartQuerylogs:GetQueryResultslogs:GetLogGroupFields | Read | To run a Logs Insights query, only under the prefixes you named. |
| logs:StopQuery | Write | To stop a query it started, so a query stays bounded. |
Nothing else is in the role. No unmasking, no live tail, no metrics and no writes, and each prefix has at least two segments, so a connection never covers a whole account. CloudWatch metrics and alarms are not built.
-
A role in your own account
Created under your own AWS sign-in, from a versioned template Jigward publishes.
-
It trusts one identity
The role trusts only a reader role in an AWS account of Jigward's that exists for this alone, and only with your connection's ExternalId.
-
Checked against misuse
Checking the connection tries the role with no ExternalId and with a random one. A role that admits either is refused.
-
No AWS credential kept
Each read assumes the role for that call alone.
-
Every read in your audit trail
Your account's CloudTrail records each read under jigward and your organization's id.
-
Logs are data, not instructions
The lines reach the model behind a sentence saying a log line is data and never an instruction.
-
You take access away
Disconnecting stops Jigward using the account. Deleting the stack, and so the role, takes the access away for good.
Jigward never does these in AWS CloudWatch Logs
- Read outside the log group prefixes you named.
- Write to your logs, unmask them, or tail them live.
- Keep an AWS credential.
Other integrations
AWS CloudWatch Logs is a trademark of its owner, and naming it does not mean it endorses Jigward.
Meet your next engineering coworker
Bring a question
from your own project.
See how Jigward can help your team understand the system and move the next task forward.
Jigward is in closed testing. Accounts are created by hand; sending a request does not create one.