gcpdiag

The vpc/WARN/2022_001 rule is a diagnostic check used to monitor project-level quotas for VPC-related resources. It identifies if your current resource usage is approaching the configured quota threshold.

Behavior:

• Rule Class: WARN (indicates a potential issue that requires attention but is not a hard failure).
• Trigger: The rule triggers a warning if your quota usage exceeds a specific threshold (default is 80%).
• Purpose: To prevent resource exhaustion by alerting you before you hit the hard limit of project-level quotas (e.g., the maximum number of VPCs allowed in a project).

The gke/Monitoring Configuration End step is a terminal step (type END) in the GKE Monitoring diagnostic runbook. Its primary purpose is to finalize the diagnostic process by interacting with the user regarding the Root Cause Analysis (RCA) results.

When this step is reached, it performs the following:

1. User Feedback: Prompts the user to indicate their satisfaction with the provided Root Cause Analysis.
2. Conditional Execution:
   • Confirmation: If the user confirms the results, the runbook execution concludes.
   • Further Action: If the user requires more information, the step can trigger additional diagnostic actions, such as generating a formal report.

Tests (lint rules and runbooks) are organized by Product, Class, and ID.

Classes:

• BP: Best practice (opinionated recommendations).
• WARN: Warnings (potential issues).
• ERR: Errors (likely incorrect configurations).
• SEC: Security issues.

ID Format: YYYY_NNN (e.g., 2021_001), where YYYY is the year written and NNN is a unique counter for that product/class combination.

When you modify the default route in a Google Cloud VPC, you should add explicit routes for Google API destination IP ranges. This ensures that traffic destined for Google APIs follows the intended path and is not inadvertently misrouted by changes to the default route.

Note: This rule does not account for tagged routes or shadowed default routes. To ensure connectivity is correctly configured, validate your routing setup using a Connectivity Test.

The Number Of Terminations step is a GATEWAY type step used during Compute Engine (GCE) investigations. It acts as a decision point to determine the scope of the investigation: whether to focus on a single VM termination or multiple terminations.

It makes this determination by evaluating the operational parameters provided to the diagnostic run, specifically checking if the investigation scope is limited to a single virtual machine (VM).

gcpdiag functions as a linter for Google Cloud Platform, where each lint rule verifies a specific aspect of a GCP project. The architecture is built on three main pillars:

1. Queries Modules: Encapsulate GCP API calls. They facilitate code reuse, improve performance through caching, and simplify lint rule implementation. Rules should never access APIs directly; they must use these modules.
2. Context Objects: Represent user-defined filters (Project ID, Regions, and Labels) used to select which resources to inspect.
3. Rule Modules: Python modules that implement specific diagnostic logic. They register with the main command and use the run_rule() method to perform checks.

Data flows from the user's Context through Queries Modules (which return Resource objects) into the Rule Modules, which then report findings via a LintReportRuleInterface object.

gcpdiag optimizes execution using caching (ensuring the same query is never executed twice) and parallel execution.

Execution Lifecycle

1. prepare_rule: Called serially in the main thread for all rules. Used for early-stage tasks like log query definition.
2. Worker Threads: Up to 10 worker threads are started to execute logging API queries and all prefetch_rule functions in parallel.
3. run_rule: The main thread executes run_rule functions (sorted alphabetically) synchronously.

Note: The rule scheduler ensures that any required prefetch_rule or logging data is completed before the corresponding run_rule begins.

The crm/Org Policy Check is an automated diagnostic step used to verify if a specific Google Cloud organization policy is effectively applied to a project.

Limitations:

• This step currently supports boolean constraints only.
• It does not support list constraints.