← Documentation

GCP & Firebase Sources

GCP and Firebase sources both tail entries from Google Cloud Logging. Under the hood they speak the same API; Firebase is shown as its own entry point because Firebase users typically don't think in "GCP" terms even though every Firebase project is technically a GCP project.

Two menu entries in + open the same sheet with different defaults:

• New Firebase Project… - icon defaults to flame.fill, helper text talks about Firebase.
• New GCP Project… - icon defaults to cloud.fill, helper text talks about GCP.

Both default to gcloud auth ADC for authentication - it's the least fiddly option once gcloud is set up (see Auth methods below). You can switch either to a Service Account Key manually; the entry point only sets defaults.

Project ID

Type the project's textual ID (e.g. my-firebase-project) or its numeric project number. Both work. On the GCP entry point, if gcloud auth application-default print-access-token returns a quota project ID, the field is pre-filled with it.

Auth methods

gcloud auth ADC (recommended)

Application Default Credentials (ADC) let LogRaker authenticate as you, using your own Google sign-in - no service account and no key file to download or secure. It's the simplest path, and once gcloud is installed it's far less fiddly than the key-file route.

One-time setup:

1. Install the gcloud CLI - follow Google's Install the gcloud CLI guide. On a Mac with Homebrew the quick way is:

   brew install --cask google-cloud-sdk

2. Sign in for ADC - run the command from Google's Set up ADC for a local development environment guide:

   gcloud auth application-default login

   A browser opens; sign in with the Google account that can read the project's logs, and approve. Your credentials are written to ~/.config/gcloud/application_default_credentials.json.
3. Set a quota project (silences the "quota project not set" warning):

   gcloud auth application-default set-quota-project YOUR_PROJECT_ID

Then in the source sheet leave Auth on gcloud auth ADC. LogRaker reads that credentials file directly - it never shells out to gcloud on the hot path.

Your account needs read access to the project's logs (roles/logging.viewer or broader - Owner/Editor already include it), so for your own projects there's nothing to grant.

Best for: developers tailing their own projects with their own Google identity.

Service Account Key

A JSON key file for a dedicated service account that holds at least roles/logging.viewer on the project. Reach for this when ADC doesn't fit - a CI machine, a shared or headless setup, or a scoped read-only identity for a project you don't own.

To create one (Google's Create service accounts and Create a service account key):

• In the console - Google Cloud Console ▸ IAM & Admin ▸ Service Accounts ▸ Create service account; grant it the Logs Viewer role (roles/logging.viewer); then on the account's Keys tab choose Add key ▸ Create new key ▸ JSON to download it. (For a Firebase project, Firebase Console ▸ Project Settings ▸ Service accounts works too.)
• Or with gcloud:

  gcloud iam service-accounts create lograker-log-reader \
    --project=YOUR_PROJECT_ID --display-name="LogRaker log reader"
  
  gcloud projects add-iam-policy-binding YOUR_PROJECT_ID \
    --member="serviceAccount:lograker-log-reader@YOUR_PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/logging.viewer"
  
  gcloud iam service-accounts keys create ~/lograker-log-reader.json \
    --iam-account=lograker-log-reader@YOUR_PROJECT_ID.iam.gserviceaccount.com

Then set Auth to Service Account Key and click Choose… to pick the JSON. Treat the key file as a secret. The key is stored in your Keychain - the source keeps the credential, not a copy of the file's path. Under the App Store sandbox you can pick anywhere inside your home folder; the file is captured via a security-scoped bookmark so subsequent launches don't need to re-pick.

Best for: read-only credentials, CI machines, projects you don't own but were granted scoped access to.

Credentials and iCloud

A Service Account Key syncs across your Macs via iCloud Keychain - set the source up once and it connects everywhere, with no need to re-pick the JSON on each Mac. The editor shows a "syncs across your Macs via iCloud Keychain" note. If you rotate or replace the key - even at the same path - re-pick the JSON with Choose… to update it on all your Macs; editing other fields leaves it untouched. gcloud ADC is not synced: it uses each Mac's own gcloud login (~/.config/gcloud), so every Mac needs its own gcloud auth application-default login - the ADC panel says "Uses gcloud credentials on each Mac - not synced." See iCloud Sync.

Test Connection

Click Test Connection. LogRaker runs a ListLogEntries(pageSize: 1) against the project using your selected auth. Three possible outcomes:

• ✓ Connected - credentials work, the project is reachable. The result says how (ADC vs. SA Key) and may add one of:

  • "Firebase project detected." - the Firebase Management API confirmed this project has Firebase enabled.
  • "Plain GCP project (no Firebase enabled)." - the Firebase Management API returned 404 for this project.
  • (no extra suffix) - the autodetect was ambiguous (caller lacks firebase.projects.get permission, or network blip).

  The autodetect is informational - it does not flip the kind. If you opened "New GCP Project" but the result says "Firebase project detected," you can save anyway, or close the sheet and re-open via "New Firebase Project" to get the Firebase defaults.

• ✗ Test failed - credentials wrong, project ID wrong, network unreachable, missing permission. The result carries the API's error message verbatim.

• (neutral / "needs credentials") - only on the SSH-style Auto-Detect result (not used by the GCP sheet).

Streams under a GCP source

GCP streams aren't "tail a file" - there's no file. A GCP stream is a saved Cloud Logging filter, built from structured controls in the stream editor. See Firebase Stream Filter or GCP Stream Filter for how the builder works.

Reading GCP log output

GCP entries are structured, so LogRaker shows more than a flat line. The features below apply only to GCP and Firebase streams.

Severity color

Each line's severity word is tinted by level so problems stand out at a glance: ERROR and the higher levels (CRITICAL, ALERT, EMERGENCY) are red, WARNING is yellow, NOTICE is teal, INFO is green, and DEBUG / DEFAULT are dim gray.

Function / service column

The function name (1st-gen Cloud Functions) or service name (Cloud Run / 2nd-gen) is shown in a fixed-width column between the severity and the message. When one stream covers several functions, the names line up and the messages align so the column is easy to scan. The full resource type is available in the entry inspector.

Inspecting an entry

⌥-click any GCP line - or right-click it and choose Inspect Entry - to open a popover with the full structured entry: severity, resource, timestamp, execution ID, span ID, trace, and the pretty-printed payload (a jsonPayload is indented and key-sorted; text, proto, and HTTP-request entries are handled too).

If the entry carries a trace, the popover shows a blue View in Cloud Trace ↗ button that opens that trace in the Google Cloud console. A trace only opens to spans if Cloud Trace actually collected them for that request, and the Trace Explorer defaults to the last hour - for an older trace you may need to widen the time window once it opens.

Execution highlighting

Every invocation of a function gets a unique execution ID, and all of that one request's lines share it. Because serverless runs many requests at once, their lines interleave by timestamp. Execution highlighting tints lines by execution so you can follow one request through the interleaving - without hiding the rest.

Choose a mode from View ▸ Execution Highlighting, or from the ••• menu in a GCP pane's toolbar (just left of the filter field):

• None - no tint.
• Highlight Selected - tints only the lines that share the selected line's execution. Click a line to follow its request; quiet and on-demand.
• Highlight All - gives every execution its own color from a 12-color palette, so concurrent requests read as distinct colored bands.

The setting is global and works in single panes, layouts, and the time-merged view. Only GCP lines are tinted; SSH and local lines stay neutral. Lines without an execution ID (e.g. some Cloud Run / scheduler entries) aren't tinted.

Filtering to one execution

To see only one request's lines instead of just tinting them, open the inspector for one of its lines and click Filter Execution. The pane then shows just that execution. Clear it with Esc, by right-clicking and choosing Clear Execution Filter, or with the inspector's Clear Filter button - and you're returned to the line you started from.