A first glance at Google Cloud Scheduler
Below you can find some information and quick insights we got from the new Google Cloud Scheduler service that we played around for some minutes.
Cloud Scheduler is a regional resource, you can select to deploy it in one of the following regions:
Note: The region cannot be changed later on.
After selecting the region, you can see that Cloud Scheduler is set up for that region. This takes around a minute. The next step is to define the name (unique for cron jobs in the project), description, schedule in unix-cron format, timezone and target. The target can be one of the following:
- App Engine
For this example, we are going with HTTP. The endpoint we are going to do a GET request to will be JSONPlaceholder that can serve a simple JSON response to us and the following endpoint in particular:
A nice thing that we observed is that after entering your cron expression, it is validated and you get a message if it is invalid. When trying to write a cron expression after a long time, I usually do a refresh about the expression. Don’t know if it’s only me, but a helper with a short explanation of the cron schedule that I have put in would be also great!
After creating the job, you are directed to a view where you can see all of your jobs, along with the following information:
- if they have run or not
- the result of the last execution
- easy way to display the job logs in Stackdriver with a click of a button
- a button to manually invoke the job
In the Stackdriver logs you can see the following information for every job execution:
- A scheduler.logging.AttemptStarted event, that logs the invocation of the scheduled job, along with some information about the job (target, endpoint, job name)
- A scheduler.logging.AttemptFinished event, that logs the completion of the job, along with the response code that we got from the GET request (`httpRequest.status` key). What was not displayed in the logs was the actual response body.
Another note is that an existing scheduled job cannot be modified, it has to be recreated to do any modification.
Cloud Scheduler is currently in Beta and subject to change. It can serve as a trigger for the rest of your pipeline, as you cannot embed any custom logic in Cloud Scheduler directly. What you can do for example is create a Cloud function and hook it up with Cloud Scheduler so that you can execute any kind of logic in a schedule. Finally, it also does automatic retries on failure (failures are considered non 2xx responses for HTTP, or non 0 for Pub/Sub).
Cloud Scheduler looks really interesting from a quick glance, as it can serve as the initial place for scheduling jobs in Google Cloud.