Logging pipeline messages

You can use the Apache Beam SDK's built-in logging infrastructure to log information during your pipeline's execution. You can use the Google Cloud Console to monitor logging information during and after your pipeline runs.

Customers who are subject to the requirements of the Health Insurance Portability and Accountability Act (known as HIPAA), note that Dataflow is eligible to be included on business associate agreements (BAA) with Google. If you would like your pipelines to be eligible for the Google Cloud BAA agreement, ensure that your pipelines only use services listed on the HIPAA compliance page.

Adding log messages to your pipeline

Java: SDK 2.x

The Apache Beam SDK for Java recommends that you log worker messages through the open source SLF4J (Simple Logging Facade for Java) library. The Apache Beam SDK for Java implements the required logging infrastructure so your Java code need only import the SLF4J API. Then, it instantiates a Logger to enable message logging within your pipeline code.

For pre-existing code and/or libraries, the Apache Beam SDK for Java sets up additional logging infrastructure. This occurs when executing on the worker to capture log messages produced by the following logging libraries for Java:

• Apache/Jakarta Commons Logging
• Java Logging API
• Log4j
• Log4j2
• SLF4J

Python

The Apache Beam SDK for Python provides the logging library package, which allows your pipeline's workers to output log messages. To use the library functions, you must import the library:

import logging

Java: SDK 1.x

Warning: Dataflow SDK 1.x for Java is unsupported as of October 16, 2018. After August 12, 2020, you can use unsupported SDKs temporarily while you upgrade your pipelines. For more information, see Using an unsupported SDK.

For information on migrating from the 1.x SDK, see Migrating from Dataflow SDK 1.x for Java.

Worker log message code example

Java: SDK 2.x

The Apache Beam WordCount example can be modified to output a log message when the word "love" is found in a line of the processed text. The added code is indicated in bold below (surrounding code is included for context).

 package org.apache.beam.examples;
 // Import SLF4J packages.
 import org.slf4j.Logger;
 import org.slf4j.LoggerFactory;
 ...
 public class WordCount {
   ...
   static class ExtractWordsFn extends DoFn<String, String> {
     // Instantiate Logger.
     // Suggestion: As shown, specify the class name of the containing class
     // (WordCount).
     private static final Logger LOG = LoggerFactory.getLogger(WordCount.class);
     ...
     @ProcessElement
     public void processElement(ProcessContext c) {
       ...
       // Output each word encountered into the output PCollection.
       for (String word : words) {
         if (!word.isEmpty()) {
           c.output(word);
         }
         // Log INFO messages when the word "love" is found.
         if(word.toLowerCase().equals("love")) {
           LOG.info("Found " + word.toLowerCase());
         }
       }
     }
   }
 ... // Remaining WordCount example code ...

Python

The Apache Beam wordcount.py example can be modified to output a log message when the word "love" is found in a line of the processed text.

# import Python logging module.
import logging

class ExtractWordsFn(beam.DoFn):
  def process(self, element):
    words = re.findall(r'[A-Za-z\']+', element)
    for word in words:
      yield word

      if word.lower() == 'love':
        # Log using the root logger at info or higher levels
        logging.info('Found : %s', word.lower())

# Remaining WordCount example code ...

Java: SDK 1.x

Warning: Dataflow SDK 1.x for Java is unsupported as of October 16, 2018. After August 12, 2020, you can use unsupported SDKs temporarily while you upgrade your pipelines. For more information, see Using an unsupported SDK.

For information on migrating from the 1.x SDK, see Migrating from Dataflow SDK 1.x for Java.

Java: SDK 2.x

If the modified WordCount pipeline is run locally using the default DirectRunner with the output sent to a local file (--output=./local-wordcounts), console output includes the added log messages:

INFO: Executing pipeline using the DirectRunner.
...
Feb 11, 2015 1:13:22 PM org.apache.beam.examples.WordCount$ExtractWordsFn processElement
INFO: Found love
Feb 11, 2015 1:13:22 PM org.apache.beam.examples.WordCount$ExtractWordsFn processElement
INFO: Found love
Feb 11, 2015 1:13:22 PM org.apache.beam.examples.WordCount$ExtractWordsFn processElement
INFO: Found love
...
INFO: Pipeline execution complete.

By default, only log lines marked INFO and higher will be sent to Cloud Logging. If you wish to change this behavior, see Setting Pipeline Worker Log Levels.

Python

If the modified WordCount pipeline is run locally using the default DirectRunner with the output sent to a local file (--output=./local-wordcounts), console output includes the added log messages:

INFO:root:Found : love
INFO:root:Found : love
INFO:root:Found : love

By default, only log lines marked INFO and higher will be sent to Cloud Logging.

Java: SDK 1.x

Warning: Dataflow SDK 1.x for Java is unsupported as of October 16, 2018. After August 12, 2020, you can use unsupported SDKs temporarily while you upgrade your pipelines. For more information, see Using an unsupported SDK.

For information on migrating from the 1.x SDK, see Migrating from Dataflow SDK 1.x for Java.

Logging limit and throttling

Worker log messages are limited to 15,000 messages every 30 seconds, per worker. If this limit is reached, a single worker log message is added saying that logging is throttled:

Throttling logger worker. It used up its 30s quota for logs in only 12.345s

No more messages are logged until the 30 second interval is over. This limit is shared by log messages generated by the Apache Beam SDK and user code.

Monitoring pipeline logs

When you run your pipeline on the Dataflow service, you can use the Dataflow Monitoring Interface to view logs emitted by your pipeline.

Dataflow worker log example

The modified WordCount pipeline can be run in the cloud with the following options:

Java: SDK 2.x

--project=WordCountExample
--output=gs://<bucket-name>/counts
--runner=DataflowRunner
--tempLocation=gs://<bucket-name>/temp
--stagingLocation=gs://<bucket-name>/binaries

Python

--project=WordCountExample
--output=gs://<bucket-name>/counts
--runner=DataflowRunner
--staging_location=gs://<bucket-name>/binaries

Java: SDK 1.x

Warning: Dataflow SDK 1.x for Java is unsupported as of October 16, 2018. After August 12, 2020, you can use unsupported SDKs temporarily while you upgrade your pipelines. For more information, see Using an unsupported SDK.

For information on migrating from the 1.x SDK, see Migrating from Dataflow SDK 1.x for Java.

Viewing job summary and status

Because the WordCount cloud pipeline uses blocking execution, console messages are output during pipeline execution. Once the job starts, a link to the Cloud Console page is output to the console, followed by the pipeline job ID:

INFO: To access the Dataflow monitoring console, please navigate to
https://console.developers.google.com/dataflow/job/2017-04-13_13_58_10-6217777367720337669
Submitted job: 2017-04-13_13_58_10-6217777367720337669

The console URL leads to the Dataflow Monitoring Interface with a summary page for the submitted job. It shows a dynamic execution graph on the left, with summary information on the right:

The Logs button opens the bottom logs panel, defaulting to show Job Log messages that report the status of the job as a whole. You can use the Minimum Severity selector to filter job progress and status messages.

Selecting a pipeline step in the graph changes the view to Step Logs generated by your code and the generated code running in the pipeline step.

To get back to Job Logs, deselect the step by clicking outside the graph or using the Close button in the right side panel.

Viewing logs

The Step Logs in the Dataflow Monitoring Interface show only the most recent log messages. You can view all Step Logs for a pipeline step in Cloud Logging by clicking the Google Cloud's operations suite link on the right side of the logs pane.

Logging also includes other infrastructure logs for your pipeline. Clicking the external link button from your Job Logs navigates to Cloud Logging with a menu to select different log types.

Here is a summary of the different log types available for viewing from the Monitoring→Logs page:

• job-message logs contain job-level messages that various components of Dataflow generate. Examples include the autoscaling configuration, when workers start up or shut down, progress on the job step, and job errors. Worker-level errors that originate from crashing user code and that are present in worker logs also propagate up to the job-message logs.
• worker logs are produced by Dataflow workers. Workers do most of the pipeline work (for example, applying your ParDos to data). Worker logs contain messages logged by your code and Dataflow.
• worker-startup logs are present on most Dataflow jobs and can capture messages related to the startup process. The startup process includes downloading a job's jars from Cloud Storage, then starting the workers. If there is a problem starting workers, these logs are a good place to look.
• shuffler logs contain messages from workers that consolidate the results of parallel pipeline operations.
• docker and kubelet logs contain messages related to these public technologies, which are used on Dataflow workers.

Setting pipeline worker log levels

Java: SDK 2.x

The default SLF4J logging level set on workers by the Apache Beam SDK for Java is INFO. All log messages of INFO or higher (INFO, WARN, ERROR) will be emitted. You can set a different default log level to support lower SLF4J logging levels (TRACE or DEBUG) or set different log levels for different packages of classes in your code.

Two pipeline options are provided to allow you to set worker log levels from the command line or programmatically:

• --defaultWorkerLogLevel=<level>: use this option to set all loggers at the specified default level. For example, the following command-line option will override the default Dataflow INFO log level, and set it to DEBUG:
  --defaultWorkerLogLevel=DEBUG
• --workerLogLevelOverrides={"<package or class>":"<level>"}: use this option to set the logging level for specified package(s) or class(es). For example, to override the default pipeline log level for the com.google.cloud.dataflow package, and set it to TRACE:
  --workerLogLevelOverrides={"com.google.cloud.dataflow":"TRACE"}
  or to override the default pipeline logging level for the com.google.cloud.Foo class, and set it to DEBUG:
  --workerLogLevelOverrides={"com.google.cloud.Foo":"DEBUG"}
  Multiple overrides can be accomplished by providing a JSON map:
  (--workerLogLevelOverrides={"<package/class>":"<level>","<package/class>":"<level>",...}).

The following example programmatically sets pipeline logging options with default values that can be overridden from the command line:

 PipelineOptions options = ...
 DataflowWorkerLoggingOptions loggingOptions = options.as(DataflowWorkerLoggingOptions.class);
 // Overrides the default log level on the worker to emit logs at TRACE or higher.
 loggingOptions.setDefaultWorkerLogLevel(Level.TRACE);
 // Overrides the Foo class and "com.google.cloud.dataflow" package to emit logs at WARN or higher.
 loggingOptions.setWorkerLogLevelOverrides(
     WorkerLogLevelOverride.forClass(Foo.class, Level.WARN),
     WorkerLogLevelOverride.forPackage(Package.getPackage("com.google.cloud.dataflow"), Level.WARN));

Python

This feature is not yet available in the Apache Beam SDK for Python.

Java: SDK 1.x

Warning: Dataflow SDK 1.x for Java is unsupported as of October 16, 2018. After August 12, 2020, you can use unsupported SDKs temporarily while you upgrade your pipelines. For more information, see Using an unsupported SDK.

For information on migrating from the 1.x SDK, see Migrating from Dataflow SDK 1.x for Java.

Viewing the log of launched BigQuery jobs

Beta

This feature is covered by the Pre-GA Offerings Terms of the Google Cloud Platform Terms of Service. Pre-GA features may have limited support, and changes to pre-GA features may not be compatible with other pre-GA versions. For more information, see the launch stage descriptions.

When using BigQuery in your Dataflow pipeline, BigQuery jobs are launched to perform various actions on your behalf, such as loading data, exporting data, and so on. For troubleshooting and monitoring purposes, the Dataflow monitoring UI has additional information on these BigQuery jobs available in the Logs panel.

Note: To view BigQuery jobs information in the Logs panel, your Dataflow job must use BigQueryIO.Read to read data from BigQuery, or use the FILE_LOADS insertion method to write data.

The BigQuery jobs information displayed in the Logs panel is stored and loaded from a BigQuery system table, so a billing cost is incurred when the underlying BigQuery table is queried.

Setting up your project

To view the BigQuery jobs information, your pipeline must use Apache Beam 2.24.0 or later; however, until that is released, you must use a development version of the Apache Beam SDK built from the main branch.

Java: SDK 2.x

1. Add the following profile to the pom.xml file for your project.

   <profiles>
     <!-- Additional profiles listed here. -->
     <profile>
       <id>snapshot</id>
       <repositories>
         <repository>
           <id>apache.snapshots</id>
           <url>https://repository.apache.org/content/repositories/snapshots</url>
         </repository>
       </repositories>
     </profile>
   </profiles>
   

2. When testing or running your project, set the profile option to the id value listed in your pom.xml and set the beam.version property to 2.24.0-SNAPSHOT or later. For example:

   mvn test -Psnapshot -Dbeam.version=2.24.0-SNAPSHOT
   

   For more snapshot values, see the snapshot index.

Python

1. Log into GitHub.

2. Navigate to the results list for successfully completed Apache Beam Python SDK builds.

3. Click a recently-completed job that was built from the main (master) branch.

4. In the side panel, click List files on Google Cloud Storage Bucket.

5. In the main panel, expand List file on Google Cloud Storage Bucket.

6. Download the zip file from the file list to a local machine or location where you run your Python project.

   The Cloud Storage bucket name is beam-wheels-staging, so you must include that when constructing your download URL. For example:

   gsutil cp gs://beam-wheels-staging/master/02bf081d0e86f16395af415cebee2812620aff4b-207975627/apache-beam-2.25.0.dev0.zip <var>SAVE_TO_LOCATION</var>
   

7. Install the downloaded zip file.

   pip install apache-beam-2.25.0.dev0.zip
   

8. When you run your Apache Beam pipeline, pass in the --sdk_location flag and reference the SDK zip file.

   --sdk_location=apache-beam-2.25.0.dev0.zip
   

Java: SDK 1.x

Warning: Dataflow SDK 1.x for Java is unsupported as of October 16, 2018. After August 12, 2020, you can use unsupported SDKs temporarily while you upgrade your pipelines. For more information, see Using an unsupported SDK.

For information on migrating from the 1.x SDK, see Migrating from Dataflow SDK 1.x for Java.

Viewing the BigQuery job details

To list the BigQuery jobs, open the BigQuery Jobs tab and select the location of the BigQuery jobs. Next, click Load BigQuery Jobs and confirm the dialog. After the query completes, the jobs list is displayed.

Note: BigQuery jobs run in the same location as the dataset they read from or write to.

Basic information about each job is provided including job id, type, duration, and so on.

For more detailed information on a specific job, click Command line in the More Info column.

In the modal window for the command line, copy the bq jobs describe command and run it locally or in Cloud Shell.

gcloud alpha bq jobs describe BIGQUERY_JOB_ID

The bq jobs describe command outputs JobStatistics, which provides further details that are useful when diagnosing a slow or stuck BigQuery job.

Alternatively, when you use BigQueryIO with a SQL query, a query job is issued. Click View query in the More Info column to see the SQL query used by the job.