I added new field in filebeat.yml
as below:
filebeat.inputs:
# Each - is an input. Most options can be set at the input level, so
# you can use different inputs for various configurations.
# Below are the input specific configurations.
- type: log
# Change to true to enable this input configuration.
enabled: true
# Paths that should be crawled and fetched. Glob based paths.
paths:
- /home/kren/ELK/docker-elk/original-logs-000/testa/feedaggregator/*
tags: ["java"]
fields:
app_id: java
#fields_under_root: true
I could not see this new field in ES via Kibana and tried using it in logstash config and doesn't work
if [fields][app_type] == "java" or "%{[fields][app_type]}" == "java" {
grok {
match => {"message" =>"%{TIMESTAMP_ISO8601:logtime}%{SPACE}%{LOGLEVEL:Loglevel}%{SPACE}%{SPACE}%{GREEDYDATA:message}"}
overwrite => ["message"]
}
}
anyone could help please? how to test it?
Thanks
found problem.
app_id: "java"
need the double quote for the string value
Related
I have this schema file in ./types/index.yaml:
$schema: "https://json-schema.org/draft/2020-12/schema"
name: Types in YAML
definitions:
flow:
type: object
properties:
slug:
type: string
flow_list:
type: 'array'
items:
$ref: "#/definitions/flow"
And I have this "instance" YAML file, in contents/en.yaml:
# yaml-language-server: $schema=../types/index.yaml#definitions/flow_list
-
slug: '123'
I would expect it to allow me to create a list of objects with the slug property on it (to get started), but instead I am getting something like this (with the ...... filled in with the full absolute OS path):
$ref 'definitions/flow_list' in 'file:///...../types/index.yaml' can not be resolved.
I am using the RedHat VSCode YAML extension. Any ideas on how to get it so I can write the array of "flows" here?
Restarting VSCode a few times seemed to fix it.
I have installed kubie and have been using it to successfully manage my multi-cluster configs.
However, recently I noticed that my default KUBECONFIG and KUBIE_KUBECONFIG paths have changed. Now when I try to download a new autopilot cluster config, it disappears.
KUBECONFIG=/var/folders/rb/2t5drg9n0f3g_p3y7rnknf_w0000gn/T/kubie-configpAMbHS.yaml
KUBIE_KUBECONFIG=/var/folders/rb/2t5drg9n0f3g_p3y7rnknf_w0000gn/T/kubie-configpAMbHS.yaml
I would like to change them back to: $HOME/.kube/config.
How can I do this?
NOTE: there are no settings in kubie.yaml to do this.
I had the same problem. I followed the instructions in the README.md - section Settings - https://github.com/sbstp/kubie/blob/master/README.md#settings and now echo $KUBECONFIG shows the right paths.
# yaml
# Force kubie to use a particular shell, if unset detect shell currently in use.
# Possible values: bash, dash, fish, xonsh, zsh
# Default: unset
shell: bash
# Configure where to look for kubernetes config files.
configs:
# Include these globs.
# Default: values listed below.
include:
- ~/.kube/config
- ~/.kube/*.yml
- ~/.kube/*.yaml
- ~/.kube/configs/*.yml
- ~/.kube/configs/*.yaml
- ~/.kube/kubie/*.yml
- ~/.kube/kubie/*.yaml
# Exclude these globs.
# Default: values listed below.
# Note: kubie's own config file is always excluded.
exclude:
- ~/.kube/kubie.yaml
# Prompt settings.
prompt:
# Disable kubie's custom prompt inside of a kubie shell. This is useful
# when you already have a prompt displaying kubernetes information.
# Default: false
disable: true
# When using recursive contexts, show depth when larger than 1.
# Default: true
show_depth: true
# When using zsh, show context and namespace on the right-hand side using RPS1.
# Default: false
zsh_use_rps1: false
# When using fish, show context and namespace on the right-hand side.
# Default: false
fish_use_rprompt: false
# When using xonsh, show context and namespace on the right-hand side.
# Default: false
xonsh_use_right_prompt: false
# Behavior
behavior:
# Make sure the namespace exists with `kubectl get namespaces` when switching
# namespaces. If you do not have the right to list namespaces, disable this.
# Default: true
validate_namespaces: true
# Enable or disable the printing of the 'CONTEXT => ...' headers when running
# `kubie exec`.
# Valid values:
# auto: Prints context headers only if stdout is a TTY. Piping/redirecting
# kubie output will auto-disable context headers.
# always: Always prints context headers, even if stdout is not a TTY.
# never: Never prints context headers.
# Default: auto
print_context_in_exec: auto
I have a question about rundeck (noob alert !)
I need to set conditionnal options variables, (don't know if its the good word).
For exemple, i want to launch a job with only one value option:
Customer01
and i need to have a relation between variable.
If i put Customer01 the other variable need to dynamic have default options:
exemple:
if
cust = Customer01ID
then ID = MyID and Oracle_schema = Myschema.
How can i make this working ?
Thanks a lot and forgive me if my problem is not clear.
A good way to do that is using cascade options, take a look at this answer.
Another way is just scripting, basing on an option selection and using an inline script step you can do anything based on the option selected, let me share a job definition based example (save as a YAML file and import to your instance to test it):
- defaultTab: nodes
description: ''
executionEnabled: true
id: e89a7cb0-2ecc-445d-b744-c1eebd540c91
loglevel: INFO
name: VariablesExample
nodeFilterEditable: false
options:
- name: customer_id
value: acme
plugins:
ExecutionLifecycle: null
scheduleEnabled: true
sequence:
commands:
- fileExtension: .sh
interpreterArgsQuoted: false
script: |-
database="none"
if [ "#option.customer_id#" = "fiat" ]; then
database="oracle"
else
database="postgresql"
fi
echo "setting $database"
scriptInterpreter: /bin/bash
keepgoing: false
strategy: node-first
uuid: e89a7cb0-2ecc-445d-b744-c1eebd540c91
Basically, the script takes the option value (#option.customer_id#) and based on that option sets the bash variable $database and does anything.
So, probably you're thinking about executing a specific step based on a job option, and for that, you can use the ruleset strategy (Rundeck Enterprise), which basically is a way to design complex workflows and a perfect scenario is to execute specific steps based on a job option selection.
In Ansible, there are several places where variables can be defined: in the inventory, in a playbook, in variable files, etc. Can anyone explain the following observations that I have made?
When defining a Boolean variable in an inventory, it MUST be capitalized (i.e., True/False), otherwise (i.e., true/false) it will not be interpreted as a Boolean but as a String.
In any of the YAML formatted files (playbooks, roles, etc.) both True/False and true/false are interpreted as Booleans.
For example, I defined two variables in an inventory:
abc=false
xyz=False
And when debugging the type of these variables inside a role...
- debug:
msg: "abc={{ abc | type_debug }} xyz={{ xyz | type_debug }}"
... then abc becomes unicode but xyz is interpreted as a bool:
ok: [localhost] => {
"msg": "abc=unicode xyz=bool"
}
However, when defining the same variables in a playbook, like this:
vars:
abc: false
xyz: False
... then both variables are recognized as bool.
I had to realize this the hard way after executing a playbook on production, running something that should not have run because of a variable set to 'false' instead of 'False' in an inventory. Thus, I'd really like to find a clear answer about how Ansible understands Booleans and how it depends on where/how the variable is defined. Should I simply always use capitalized True/False to be on the safe side? Is it valid to say that booleans in YAML files (with format key: value) are case-insensitive, while in properties files (with format key=value) they are case-sensitive? Any deeper insights would be highly appreciated.
Variables defined in YAML files (playbooks, vars_files, YAML-format inventories)
YAML principles
Playbooks, vars_files, and inventory files written in YAML are processed by a YAML parser first. It allows several aliases for values which will be stored as Boolean type: yes/no, true/false, on/off, defined in several cases: true/True/TRUE (thus they are not truly case-insensitive).
YAML definition specifies possible values as:
y|Y|yes|Yes|YES|n|N|no|No|NO
|true|True|TRUE|false|False|FALSE
|on|On|ON|off|Off|OFF
Ansible docs confirm that:
You can also specify a boolean value (true/false) in several forms:
create_key: yes
needs_agent: no
knows_oop: True
likes_emacs: TRUE
uses_cvs: false
Variables defined in INI-format inventory files
Python principles
When Ansible reads an INI-format inventory, it processes the variables using Python built-in types:
Values passed in using the key=value syntax are interpreted as Python literal structure (strings, numbers, tuples, lists, dicts, booleans, None), alternatively as string. For example var=FALSE would create a string equal to FALSE.
If the value specified matches string True or False (starting with a capital letter) the type is set to Boolean, otherwise it is treated as string (unless it matches another type).
Variables defined through --extra_vars CLI parameter
All strings
All variables passed as extra-vars in CLI are of string type.
The YAML principles define the possible Boolean values that are accepted by Ansible. However after parsing only two values remain (true and false), these are valid in JSON too, so if you do some things with these values in Ansible, then true and false are good choices. Also the Ansible documentation states
Use lowercase ‘true’ or ‘false’ for boolean values in dictionaries if
you want to be compatible with default yamllint options.
#!/usr/bin/env ansible-playbook
---
- name: true or false?
hosts: all
gather_facts: false
tasks:
- name: "all these boolean inputs evaluate to 'true'"
debug:
msg: "{{ item }}"
with_items:
- true
- True
- TRUE
- yes
- Yes
- YES
- on
- On
- ON
- name: "all these boolean inputs evaluate to 'false'"
debug:
msg: "{{ item }}"
with_items:
- false
- False
- FALSE
- no
- No
- NO
- off
- Off
- OFF
The YAML principles define the possible Boolean values that are accepted by Ansible. However after parsing only two values remain (true and false), these are valid in JSON too, so if you do things with JSON in Ansible, then true and false are good choices. The best IMHO.
#!/usr/bin/env ansible-playbook
---
- name: true or false?
hosts: all
gather_facts: false
tasks:
- name: "all these boolean inputs evaluate to 'true'"
debug:
msg: "{{ item }}"
with_items:
- true
- True
- TRUE
- yes
- Yes
- YES
- on
- On
- ON
- name: "all these boolean inputs evaluate to 'false'"
debug:
msg: "{{ item }}"
with_items:
- false
- False
- FALSE
- no
- No
- NO
- off
- Off
- OFF
I'm working on an ansible-playbook which should help to generate build agents for a continuous delivery pipeline. Among other issues, I'll need to install an oracle client on such an agent. I want to do something like
- name: "Provide response file"
copy: src=/custom.rsp dest=/opt/oracle
Within the custom.rsp file I've got some variables to be substituted. Normally, one could do it with a separate shell command like this:
- name: "Substitute Vars"
shell: "sed 's|<PARAMETER>|<VALUE>|g' -i /opt/oracle/custom.rsp"
I don't like it, though. There should be a more convinient way to do this. Anybody giving me a hint?
You want to be using a template rather than copying a static file.
Also, when using the copy or template modules, the dest parameter is a full path AND filename, not just a path. So if you want to end up with a copy of custom.rsp in the directory /opt/oracle then you need to do this:
- name: "Provide response file"
template: src=/custom.rsp dest=/opt/oracle/custom.rsp
I'm going to extend Bruce's answer with an example:
This is part of my inventory.yaml:
kafka_stage:
children:
kafka_with_zookeeper_stage:
kafka_only_stage:
vars:
zookeeper_hosts: "kafka-stage01:2181,kafka-stage02:2181,kafka-stage03:2181"
kafka_with_zookeeper_stage:
hosts:
kafka-stage01:
broker_id: 0
kafka-stage02:
broker_id: 1
vars:
services:
kafka:
zookeeper:
This is part of a configuration file:
# The id of the broker. This must be set to a unique integer for each broker.
broker.id={{ broker_id }}
# {{ zookeeper_hosts }}
advertised.listeners=PLAINTEXT://{{ ansible_host }}:9092
# {{ services }}
This command in a playbook:
- name: Copy to Host
ansible.builtin.template:
src: my_configfile.properties
dest: /tmp/hejsan.properties
Gave me this on the remote host kafka-stage02:
# The id of the broker. This must be set to a unique integer for each broker.
broker.id=1
# kafka-stage01:2181,kafka-stage02:2181,kafka-stage03:2181
advertised.listeners=PLAINTEXT://kafka-stage02:9092
# {'kafka': None, 'zookeeper': None}