VPN ਵਰਤੋਂਕਾਰਨਾਮ ਲੌਗ ਪਾਈਪਲਾਈਨ ਤੋਂ ਕਿੱਥੇ ਗਾਇਬ ਹੁੰਦਾ ਹੈ?
ਲੌਗ ਦੀ ਪਰਦੇਦਾਰੀ ਕੰਟਰੋਲ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਗੇਟਵੇ ਘਟਨਾ, ਸੰਗ੍ਰਹਿਕਰਤਾ ਦੀ ਕੱਚੀ ਕਾਪੀ, ਸੂਚੀਬੱਧ ਘਟਨਾ ਅਤੇ ਖੋਜ ਸਮੇਂ ਦਾ ਖੇਤਰ ਤੁਲਨਾ ਕਰੋ।
ਸੈਸ਼ਨ ਡੈਸ਼ਬੋਰਡ ਉੱਤੇ ਦਿਖਦੇ ਹਨ ਪਰ ਵਰਤੋਂਕਾਰਨਾਮ ਦਾ ਕਾਲਮ ਖਾਲੀ ਰਹਿੰਦਾ ਹੈ, ਅਤੇ ਪਹਿਲੀ ਪ੍ਰਵਿਰਤੀ ਪਾਰਸਰ ਨੂੰ ਦੋਸ਼ ਦੇਣ ਦੀ ਹੁੰਦੀ ਹੈ। ਉਹ ਪ੍ਰਵਿਰਤੀ ਤਿੰਨ ਪਹਿਲੇ ਪੜਾਵਾਂ ਨੂੰ ਛੱਡ ਦਿੰਦੀ ਹੈ ਜਿੱਥੇ ਮੁੱਲ ਗੁਆਚ ਸਕਦਾ ਸੀ। ਗੇਟਵੇ ਨੀਤੀ ਅਨੁਸਾਰ ਪਛਾਣ ਲੁਕਾ ਸਕਦਾ ਹੈ, ਇਨਜੈਸ਼ਨ ਨਿਯਮ ਉਸ ਨੂੰ ਸੂਚੀਬੱਧ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਮਿਟਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਖੋਜ ਸਮੇਂ ਦਾ ਨਿਕਾਸ਼ ਉਸ ਦਾ ਨਾਮ ਰੱਖਣ ਵਿੱਚ ਬਸ ਅਸਫਲ ਹੋ ਸਕਦਾ ਹੈ। ਸੁਧਾਰ ਇਸ ਉੱਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਕਿਹੜੀ ਹੱਦ ਨੂੰ ਜ਼ਿੰਮੇਵਾਰ ਸਾਬਤ ਕਰ ਸਕਦੇ ਹੋ, ਇਸ ਲਈ ਲਾਹੇਵੰਦ ਕੰਮ ਸੰਰਚਨਾ ਨਹੀਂ, ਤੁਲਨਾ ਹੈ।
ਡੈਸ਼ਬੋਰਡ ਤੋਂ ਨਹੀਂ, ਇੱਕ ਘਟਨਾ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ
ਇੱਕ ਹੀ ਪ੍ਰਮਾਣਿਕਤਾ ਘਟਨਾ ਚੁਣੋ ਅਤੇ ਲਿਖੋ ਕਿ ਉਸ ਨੂੰ ਕੀ ਪਛਾਣਦਾ ਹੈ: ਗੇਟਵੇ ਦਾ ਮਾਡਲ ਅਤੇ ਸੰਸਕਰਣ, ਪ੍ਰਮਾਣਿਕਤਾ ਢੰਗ, ਘਟਨਾ ਪਛਾਣਕਰਤਾ, ਸਮਾਂ-ਛਾਪ ਅਤੇ ਸਰੋਤ ਪਤਾ। ਵਰਤੋਂਕਾਰਨਾਮ ਠੀਕ ਉਸੇ ਤਰ੍ਹਾਂ ਜੋੜੋ ਜਿਵੇਂ ਵਿਅਕਤੀ ਨੇ ਟਾਈਪ ਕੀਤਾ ਸੀ, ਵੱਡੇ ਅਤੇ ਛੋਟੇ ਅੱਖਰਾਂ ਸਮੇਤ, ਕਿਉਂਕਿ ਅੱਖਰ-ਸੰਵੇਦੀ ਖੋਜ ਕਿਸੇ ਮੌਜੂਦ ਖੇਤਰ ਨੂੰ ਲੁਕਾ ਸਕਦੀ ਹੈ। ਉਸ ਘਟਨਾ ਨੂੰ ਹਰ ਅਗਲੀ ਤੁਲਨਾ ਲਈ ਸੰਦਰਭ ਮੰਨੋ।
ਘਟਨਾ ਦੀਆਂ ਕਿਸਮਾਂ ਇੱਕੋ ਸਕੀਮਾ ਸਾਂਝੀ ਨਹੀਂ ਕਰਦੀਆਂ। ਅਸਫਲ ਕੋਸ਼ਿਸ਼, ਕਲਾਇੰਟ ਤੋਂ ਬਿਨਾਂ ਸਫਲ ਲੌਗਇਨ ਅਤੇ ਟਨਲ ਦਾ ਦੁਬਾਰਾ ਜੁੜਨਾ ਹਰ ਇੱਕ ਵੱਖਰੇ ਖੇਤਰ ਬਣਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਕੁਝ ਗੇਟਵੇ ਪਛਾਣ ਛੱਡ ਦਿੰਦੇ ਹਨ ਜਦੋਂ ਕੋਸ਼ਿਸ਼ ਕਦੇ ਵਰਤੋਂਕਾਰ ਪ੍ਰਮਾਣਿਕਤਾ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚੀ। ਇਸ ਲਈ ਇੱਕ ਘਟਨਾ ਕਿਸਮ ਵਿੱਚ ਖਾਲੀ ਕਾਲਮ ਪਾਈਪਲਾਈਨ ਸਮੱਸਿਆ ਦਾ ਕਮਜ਼ੋਰ ਸਬੂਤ ਹੈ।
ਸੱਚੇ ਕਰਮਚਾਰੀ ਖਾਤੇ ਦੀ ਥਾਂ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਟੈਸਟ ਪਛਾਣ ਨਾਲ ਕੰਮ ਕਰੋ, ਅਤੇ ਤੁਲਨਾ ਨੂੰ ਲੌਗ ਡੇਟਾ ਉੱਤੇ ਪਹਿਲਾਂ ਹੀ ਲਾਗੂ ਪਹੁੰਚ ਨਿਯਮਾਂ ਦੇ ਅੰਦਰ ਰੱਖੋ। ਸਿਰਫ਼ ਨਮੂਨਾ ਲੈਣ ਲਈ ਵਿਸਥਾਰਤ ਪ੍ਰਮਾਣਿਕਤਾ ਲੌਗਿੰਗ ਵਿਆਪਕ ਰੂਪ ਵਿੱਚ ਚਾਲੂ ਕਰਨਾ ਉਸ ਸਿਸਟਮ ਨੂੰ ਬਦਲ ਦਿੰਦਾ ਹੈ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਮਾਪਣਾ ਚਾਹੁੰਦੇ ਹੋ।
ਚਾਰ ਹੱਦਾਂ ਦੀ ਕ੍ਰਮ ਵਿੱਚ ਤੁਲਨਾ ਕਰੋ
ਮੁੱਲ ਚਾਰ ਵਿੱਚੋਂ ਕਿਸੇ ਇੱਕ ਬਿੰਦੂ ਉੱਤੇ ਗਾਇਬ ਹੋ ਸਕਦਾ ਹੈ। ਹਰ ਬਿੰਦੂ ਦਾ ਵੱਖਰਾ ਮਾਲਕ ਅਤੇ ਵੱਖਰਾ ਸੁਧਾਰ ਹੈ।
| Boundary | What to compare | A gap means |
|---|---|---|
| Gateway event view | The device's own event display and logging policy | The identity was masked or never emitted |
| Collector receive | The raw event as received, before parsing | Transport, filter or source selection dropped it |
| Index-time pipeline | Transforms applied before storage | Redaction or rewriting removed the value |
| Search-time extraction | The field name and regex used by the query | The label does not match the stored key |
ਜਿੱਥੇ ਮੁੱਲ ਗਾਇਬ ਹੁੰਦਾ ਹੈ ਉਸ ਪਹਿਲੀ ਹੱਦ ਉੱਤੇ ਰੁਕੋ। ਡਿਵਾਈਸ ਦੇ ਦ੍ਰਿਸ਼ ਅਤੇ ਕੱਚੀ ਕਾਪੀ ਵਿਚਕਾਰ ਅੰਤਰ ਆਵਾਜਾਈ ਜਾਂ ਸੰਗ੍ਰਹਿਕਰਤਾ ਸੰਰਚਨਾ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ; ਉੱਥੇ ਮੇਲ ਹੋਣ ਪਰ ਸੂਚੀਬੱਧ ਘਟਨਾ ਵਿੱਚ ਮੁੱਲ ਨਾ ਹੋਣਾ ਕਿਸੇ ਰੂਪਾਂਤਰਣ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ; ਸੂਚੀਬੱਧ ਘਟਨਾ ਵਿੱਚ ਮੁੱਲ ਹੋਣ ਪਰ ਡੈਸ਼ਬੋਰਡ ਉੱਤੇ ਨਾ ਹੋਣਾ ਨਿਕਾਸ਼ ਜਾਂ ਕੁਐਰੀ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ।
ਇਹ ਕ੍ਰਮ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਹਰ ਅਗਲਾ ਪੜਾਅ ਸਿਰਫ਼ ਜਾਣਕਾਰੀ ਗੁਆ ਸਕਦਾ ਹੈ, ਉਸ ਨੂੰ ਕਦੇ ਬਹਾਲ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਰੈਗੂਲਰ ਐਕਸਪ੍ਰੈਸ਼ਨ ਉਸ ਸਤਰ ਨੂੰ ਵਾਪਸ ਨਹੀਂ ਲਿਆ ਸਕਦਾ ਜਿਸ ਨੂੰ ਕਿਸੇ ਪਹਿਲੇ ਪੜਾਅ ਨੇ ਪਲੇਸਹੋਲਡਰ ਨਾਲ ਬਦਲ ਦਿੱਤਾ ਸੀ, ਅਤੇ ਪਰਦੇਦਾਰੀ ਸੈਟਿੰਗ ਉਸ ਮੁੱਲ ਦੀ ਵਿਆਖਿਆ ਨਹੀਂ ਕਰ ਸਕਦੀ ਜੋ ਕਦੇ ਭੇਜਿਆ ਹੀ ਨਹੀਂ ਗਿਆ।
ਸਰੋਤ ਉੱਤੇ ਲੁਕਾਉਣਾ ਨੀਤੀ ਹੈ, ਪਾਰਸਰ ਦੀ ਗਲਤੀ ਨਹੀਂ
Cisco ਦਾ ASA ਲੌਗਿੰਗ ਦਸਤਾਵੇਜ਼ ਵਰਤੋਂਕਾਰਨਾਮ ਲੁਕਾਉਣ ਨੂੰ ਸੰਰਚਨਾਯੋਗ ਵਿਵਹਾਰ ਵਜੋਂ ਦੱਸਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਇਹ ਵੀ ਸ਼ਾਮਲ ਹੈ ਕਿ ਅਵੈਧ ਜਾਂ ਅਣਜਾਣ ਵਰਤੋਂਕਾਰਨਾਮ ਕਿਵੇਂ ਦਿਖਾਏ ਜਾਂਦੇ ਹਨ। ਇਸ ਲਈ ਸਰੋਤ ਘਟਨਾ ਵਿੱਚ ਲੁਕਾਈ ਪਛਾਣ ਠੀਕ ਉਹੀ ਹੋ ਸਕਦੀ ਹੈ ਜੋ ਪਰਦੇਦਾਰੀ ਨੀਤੀ ਮੰਗਦੀ ਹੈ, ਅਤੇ ਉਸ ਨੂੰ ਪਾਰਸਿੰਗ ਅਸਫਲਤਾ ਮੰਨਣਾ ਇੱਕ ਅਜਿਹੀ ਬੇਨਤੀ ਵੱਲ ਲੈ ਜਾਂਦਾ ਹੈ ਜੋ ਕੰਟਰੋਲ ਨੂੰ ਕਮਜ਼ੋਰ ਕਰਦੀ ਹੈ।
ਸਹੀ ਪੇਸ਼ਕਾਰੀ ਸੰਸਕਰਣ ਅਤੇ ਸੁਨੇਹਾ ਕਿਸਮ ਉੱਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ। ਇੱਕ ਘਟਨਾ ਪਲੇਸਹੋਲਡਰ ਰੱਖ ਸਕਦੀ ਹੈ, ਦੂਜੀ ਖੇਤਰ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਛੱਡ ਸਕਦੀ ਹੈ, ਅਤੇ ਪ੍ਰਮਾਣਿਕਤਾ ਅਸਫਲਤਾ ਵਿੱਚ ਕਦੇ ਨਾਮ ਵੀ ਨਹੀਂ ਹੋ ਸਕਦਾ। ਹਰ ਗੁੰਮ ਪਛਾਣ ਉੱਤੇ ਪੁਰਾਣੀ ਬੱਗ ਰਿਪੋਰਟ ਲਾਗੂ ਕਰਨ ਦੀ ਥਾਂ ਉਸ ਖਾਸ ਘਟਨਾ ਲਈ ਦਸਤਾਵੇਜ਼ੀ ਵਿਵਹਾਰ ਜਾਂਚੋ।
ਜਦੋਂ ਲੁਕਾਉਣਾ ਜਾਣ-ਬੁੱਝ ਕੇ ਹੋਵੇ, ਸਵਾਲ ਖੇਤਰ ਨੂੰ ਕਿਵੇਂ ਬਹਾਲ ਕਰਨਾ ਹੈ ਤੋਂ ਬਦਲ ਕੇ ਇਹ ਹੋ ਜਾਂਦਾ ਹੈ ਕਿ ਲੇਖਾ-ਪੜਤਾਲ ਦੀ ਲੋੜ ਕਿਸੇ ਹੋਰ ਢੰਗ ਨਾਲ ਪੂਰੀ ਹੋ ਸਕਦੀ ਹੈ ਜਾਂ ਨਹੀਂ। ਸੈਸ਼ਨ ਪਛਾਣਕਰਤਾ, ਛੋਟੇ ਸਮੂਹ ਕੋਲ ਰੱਖੀ ਨਿਯੰਤਰਿਤ ਪਛਾਣ ਮੈਪਿੰਗ, ਜਾਂ ਤੰਗ ਅਧਿਕ੍ਰਿਤ ਘਟਨਾ ਫੀਡ ਅਕਸਰ ਹਰ ਕੋਸ਼ਿਸ਼ ਕੀਤੇ ਵਰਤੋਂਕਾਰਨਾਮ ਨੂੰ ਹਰ ਲੌਗ ਪਾਠਕ ਸਾਹਮਣੇ ਰੱਖੇ ਬਿਨਾਂ ਲੋੜ ਪੂਰੀ ਕਰ ਦਿੰਦੇ ਹਨ।
ਸੂਚੀਬੱਧ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਦਾ ਅਨਾਮੀਕਰਨ ਮੋੜਿਆ ਨਹੀਂ ਜਾ ਸਕਦਾ
ਘਟਨਾ ਪ੍ਰੋਸੈਸਿੰਗ ਬਾਰੇ Splunk ਦਾ ਦਸਤਾਵੇਜ਼ sed ਸਮੀਕਰਨਾਂ ਅਤੇ ਰੂਪਾਂਤਰਣਾਂ ਰਾਹੀਂ ਅਨਾਮੀਕਰਨ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ ਜੋ ਸੂਚੀਬੱਧ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਡੇਟਾ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਦੇ ਜਾਂ ਹਟਾਉਂਦੇ ਹਨ। ਠੀਕ ਉਹੀ ਥਾਂ ਮੁੱਖ ਗੱਲ ਹੈ: ਕੱਚੀ ਘਟਨਾ ਅੰਦਰ ਆਉਂਦਿਆਂ ਹੀ ਬਦਲ ਜਾਂਦੀ ਹੈ, ਇਸ ਲਈ ਖੋਜ ਸਮੇਂ ਦੇ ਨਿਕਾਸ਼ ਕੋਲ ਲੱਭਣ ਲਈ ਕੁਝ ਨਹੀਂ ਬਚਦਾ।
ਸੂਚੀਬੱਧ ਸਮੇਂ ਦਾ ਸੰਪਾਦਨ ਅਤੇ ਖੋਜ ਸਮੇਂ ਦਾ ਖੇਤਰ ਨਿਕਾਸ਼ ਵੱਖਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਹੱਲ ਕਰਦੇ ਹਨ। ਸੰਪਾਦਨ ਸੀਮਿਤ ਕਰਦਾ ਹੈ ਕਿ ਮੁੱਲ ਕਦੇ ਕੌਣ ਦੇਖ ਸਕਦਾ ਹੈ; ਨਿਕਾਸ਼ ਸਿਰਫ਼ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਕੁਐਰੀ ਕਿਹੜਾ ਨਾਮ ਵਰਤਦੀ ਹੈ। ਹੈਸ਼ਿੰਗ ਇੱਕ ਮੱਧ ਵਿਕਲਪ ਹੈ ਜੋ ਸਹਿਸੰਬੰਧ ਬਚਾਉਂਦਾ ਹੈ, ਪਰ ਛੋਟੇ ਵਰਤੋਂਕਾਰਨਾਮ ਖੇਤਰ ਉੱਤੇ ਸਥਿਰ ਹੈਸ਼ ਤਦ ਵੀ ਪਛਾਣ ਦਿੰਦਾ ਹੈ ਜਦੋਂ ਕੋਈ ਉਸ ਵਿਰੁੱਧ ਸੰਭਾਵੀ ਨਾਮ ਜਾਂਚ ਸਕਦਾ ਹੈ।
ਜੇ ਸੰਗ੍ਰਹਿਤ ਘਟਨਾ ਵਿੱਚ ਅਜੇ ਵੀ ਪਛਾਣ ਹੈ, ਸਮੱਸਿਆ ਹੇਠਾਂ ਹੈ: ਸਰੋਤ ਕਿਸਮ, ਲਾਈਨ ਵੰਡ, ਵਿਭਾਜਕ ਸੰਭਾਲ, ਖੇਤਰ ਉਪਨਾਮ ਜਾਂ ਕੁਐਰੀ ਆਪ। ਇਹ ਆਮ ਪਾਰਸਿੰਗ ਸੁਧਾਰ ਹਨ ਅਤੇ ਇਹ ਪਰਦੇਦਾਰੀ ਹੱਦ ਨੂੰ ਨਹੀਂ ਛੂਹਦੇ।
ਹੱਦ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਸੁਧਾਰ ਚੁਣੋ
ਤਿੰਨ ਸ਼ਰਤਾਂ ਪ੍ਰਤੀਕਿਰਿਆ ਤੈਅ ਕਰਦੀਆਂ ਹਨ। ਪਹਿਲੀ, ਕੀ ਪਰਦੇਦਾਰੀ ਨੀਤੀ ਪਛਾਣ ਨੂੰ ਬਾਹਰ ਰੱਖਣਾ ਚਾਹੁੰਦੀ ਹੈ? ਦੂਜੀ, ਕੀ ਲੇਖਾ-ਪੜਤਾਲ ਜਾਂ ਜਾਂਚ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਪਛਾਣ, ਉਪਨਾਮ, ਜਾਂ ਸਿਰਫ਼ ਸੈਸ਼ਨ ਚਾਹੀਦਾ ਹੈ? ਤੀਜੀ, ਮੁੱਲ ਕਿਹੜੀ ਹੱਦ ਉੱਤੇ ਚਾਹੀਦਾ ਹੈ — ਸੰਗ੍ਰਹਿ, ਸੰਭਾਲ ਜਾਂ ਪੇਸ਼ਕਾਰੀ?
ਜੇ ਨੀਤੀ ਬਾਹਰ ਰੱਖਣਾ ਚਾਹੁੰਦੀ ਹੈ, ਤਾਂ ਕੰਟਰੋਲ ਨਹੀਂ, ਲੋੜ ਜਾਂ ਪੇਸ਼ਕਾਰੀ ਬਦਲੋ। ਜੇ ਨੀਤੀ ਪਛਾਣ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ ਪਰ ਸੰਗ੍ਰਹਿ ਉਸ ਨੂੰ ਛੱਡ ਦਿੰਦਾ ਹੈ, ਸੰਗ੍ਰਹਿਕਰਤਾ ਸੁਧਾਰੋ ਅਤੇ ਕੱਚੀ ਘਟਨਾ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ। ਜੇ ਸੰਭਾਲ ਅਟੁੱਟ ਹੈ, ਨਿਕਾਸ਼ ਸੁਧਾਰੋ ਅਤੇ ਸ਼ੁਰੂ ਵਿੱਚ ਕੈਦ ਕੀਤੀ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਘਟਨਾ ਦੇ ਵਿਰੁੱਧ ਉਸ ਦੀ ਪਰਖ ਕਰੋ।
ਤਬਦੀਲੀ ਰਿਕਾਰਡ ਵਿੱਚ ਹੱਦ ਦਾ ਨਾਮ ਦੇ ਕੇ ਜਾਂਚ ਖ਼ਤਮ ਕਰੋ: ਸਰੋਤ ਉੱਤੇ ਲੁਕਾਈ, ਇਨਜੈਸ਼ਨ ਦੌਰਾਨ ਹਟਾਈ, ਜਾਂ ਨਿਕਾਸ਼ ਤੋਂ ਖੁੰਝੀ। ਉਹ ਇੱਕ ਵਾਕ ਅਗਲੇ ਇੰਜੀਨੀਅਰ ਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਪਹਿਲਾਂ ਕਿੱਥੇ ਵੇਖਣਾ ਹੈ, ਅਤੇ ਇਹ ਡੈਸ਼ਬੋਰਡ ਦੀ ਸ਼ਿਕਾਇਤ ਨੂੰ ਚੁੱਪਚਾਪ ਬੰਦ ਕੀਤੀ ਪਰਦੇਦਾਰੀ ਸੁਵਿਧਾ ਵਿੱਚ ਬਦਲਣ ਤੋਂ ਰੋਕਦਾ ਹੈ।