Parameters for use in Lightweight and Journey/Browser Monitors

[Ben_Berg1 (Ben Berg)]

I am using the new synthetics approach using a Typescript project. All docs indicate that parameters/secrets can be used in both lightweight and journey/browser code. I am not able to do so can do either or.
Docs indicate having this in the synthetics.config.ts:

export default (env) => {
  let my_url = "http://localhost:8080";
  if (env === "production") {
    my_url = "https://elastic.github.io/synthetics-demo/"
  }
  return {
    params: {
      my_url,
    },
  };
};

But the generated project creates something like this:
export default env => {
const config: SyntheticsConfig = {

Anyone using lightweight and journey monitors using the same parameters? What am I missing?

[Wolfram_Haussig]

Hello Ben,

I think both is correct, it is just a different style of writing. But I agree, the documentation and generated code should allign.

Personally, I prefer the style that is generated automatically over the docs example.

Best regards
Wolfram

[shahzad31 (Shahzad)]

Hello @Ben_Berg1 we will certainly discuss the feedback regarding the docs.

How are you trying params in lightweight monitors?

I just tried this syntax and it works for me

heartbeat.monitors:
- type: http
  name: Todos Lightweight
  id: todos-lightweight
  enabled: true
  urls: "${devUrl}"
  schedule: '@every 3m'
  timeout: 16s
  alert.status.enabled: true

and config file as

export default env => {
  const config: SyntheticsConfig = {
    params: {
      devUrl: 'https://elastic.github.io/synthetics-demo/',
    },

   // rest of the config 

  return config;
};

[Ben_Berg1 (Ben Berg)]

Thanks for the reply.
When i push to elastic the parameter is not replaced for lightweight but is for synthetics, here is my monitor code:

heartbeat.monitors:
- type: http
  name: Manager Login ${environment}
  id: "manager-login-${environment}"
  enabled: true
  urls: "https://${baseUrl}/manager/"
  schedule: '@every 5m'
  timeout: 16s
  alert.status.enabled: false

And my config file:

import type { SyntheticsConfig } from '@elastic/synthetics';
import monitoringConfig from './config.json';

export default env => {
  const config: SyntheticsConfig = {
    params: {
      baseUrl: monitoringConfig.baseUrl,
      managerLoginEmail: monitoringConfig.managerLoginEmail,
      managerLoginPassword: monitoringConfig.managerLoginPassword,
      environment: monitoringConfig.environment
    },
    playwrightOptions: {
      ignoreHTTPSErrors: false
    },
    /**
     * Configure global monitor settings
     */
    monitor: {
      schedule: 10,
      locations: [],
      privateLocations: [monitoringConfig.monitorPrivateLocations]
    },
    /**
     * Project monitors settings
     */
    project: {
      id: `${monitoringConfig.applicationName}-${monitoringConfig.environment}`,
      url: monitoringConfig.elasticCloudUrl,
      space: monitoringConfig.spaceName,
    },
  }
  const params = {
    baseUrl: monitoringConfig.baseUrl,
    managerLoginEmail: monitoringConfig.managerLoginEmail,
    managerLoginPassword: monitoringConfig.managerLoginPassword,
    environment: monitoringConfig.environment

  };
  return config;
};

config.json is a simple JSON object with key/values - have a local version and is transformed in CI/CD for different environments and works as expected for synthetics. Note we are still on 8.7.1 so wonder if a bug that we should upgrade? Also running from a private location that is the correct docker image - synthetic monitor runs fine.
Here is a screenshot of the lightweight monitor deployed to elastic:

and the journey/synthetic deployed to elastic:

Thanks again for the reply/review/comments/validation attempts.
Ben

[shahzad31 (Shahzad)]

@Ben_Berg1 lightweight params support was added in 8.8.0 so yeah you will have to upgrade

[Ben_Berg1 (Ben Berg)]

Awesome - thanks for identifying. Will give that a shot. Nice work on this feature - will be a nice win to consolidate heartbeat, synthetics, etc.

[Ben_Berg1 (Ben Berg)]

Upgraded to 8.8.1 and deleted and pushed from project again and still not seeing parameters being replaced.

Updated the fleet agent to 8.8.1 as well.
Anything else I can check? This is blocking hard now as heartbeat monitors appear to be depreciated in 8.8.1 as i not longer see those in uptime.

[shahzad31 (Shahzad)]

@Ben_Berg1 can you take a look at the actual document that you are receiving from heartbeat?

We actually discussed this internally and in the UI we don't display the parsed value which i can understand is bit confusing. I will create an issue to discuss this and whether UI should show the parsed value.

You can take a look at the actual result you are receiving in discover by creating a data view with synthetics-* pattern.

Another issue that i can think of is migration. Change a config a bit and push the monitor again.

or you can simply test a new monitor.

let me know if you need help with checking data in discover.

Regards

[Ben_Berg1 (Ben Berg)]

Thanks @shahzad31 - there was no data in the synthetics index but I have it working now. It appears the id field for the heartbeat.yml cannot contain parameters. Once i removed the parameter there it did go from pending to running the monitor.
Good to know on the UI. Be interested in hearing others thoughts there, I could see either way being useful. I did notice in the list view the name isn't parsed but within the monitor view the values appear to be parsed which i think is valuable.

I think i will just move some of the metadata i was trying to put in the id to separate and put in tags. I won't have same ID in any monitors in the same project as each environment has own project ID.

On a similar but separate note, can environment variables be defined outside of the config and used by the synthetics? I am using AWS and would like some of the data to come from environment variables defined on the ECS task (env vars for the docker agent) to be used. Is this a good approach? Thinking on how to keep some secure values out of the parameters defined in monitor and we use AWS secrets manager/docker environment variables currently in heartbeat monitors. Assuming it will work same way but thought I'd ask before testing/validating.
Thanks again for your help.

[Ben_Berg1 (Ben Berg)]

Appears the monitor.tags is not working as documented here - i would expect both synthetic and lightweight monitors to be tagged with values.

 monitor: {
      schedule: 15,
      locations: [],
      privateLocations: [monitoringConfig.monitorPrivateLocations],
      tags: [monitoringConfig.environment,`test`]
    },

If i put in the journey it does show up:

journey(`Buildium Manager Login`, async ({ page, params }) => {

  monitor.use({
    id: `${params.environment} - buildium-manager-login`,
    tags: [params.environment]
  });

and in lightweight it works with hardcoded values but parameters are not parsed:

heartbeat.monitors:
- type: http
  name: "Manager Login Page ${environment}"
  id: "manager-login"
  enabled: true
  urls: "https://${baseUrl}/manager/"
  schedule: '@every 5m'
  timeout: 25s
  alert.status.enabled: false
  tags: 
    - ${environment}

Any know issues around tags?

[shahzad31 (Shahzad)]

i have created an issue for id field params

Validate params for id field

I will take a look at tags and env vars question and will respond.

[vigneshshanmugam]

Hi @Ben_Berg1,

The monitor tags not getting applied to all pushed monitors is already tracked in this issue where we are consolidating how tags should behave similar to other parameters like locations.

Also, I would like to understand more about your use case on why you would want to tie in your monitor name with environment when the URL for the monitor is going to be the same in the latest test.

Thanks,
Vignesh

[Ben_Berg1 (Ben Berg)]

Thanks for the link @vigneshshanmugam .
For using the environment in monitor name it is to be able to see what environment the synthetic is running on easily. We have 2 elastic cloud deployments currently, one for local, dev, and staging and one for prod.
We deploy monitors for dev and staging through CI/CD and the urls would be for different environments. Local is used for local testing of synthetics and have basically same configuration as dev but aren't super critical expect during development of synthetic monitors.
We could use tags likely just as well to filter and seems filtering by project also works - just trying to find a fool proof way for consumers of the monitor data to know what environment they are working with and the environment name in the name seems like a very hard thing to miss!
Thanks again!
Ben