NTFS provides something called journal. I think it is a record of actions like file rename/move/deletes done by any application. Can I get the similar journal or log on Linux + BTRFS? One BTRFS partition, which is used by only one Linux installation.
Example of NTFS Journal on Google Images:
I think you misunderstand the purpose of the journal. It is not a log of the actions done by applications, and doesn't record which application caused a change. It is not intended for users or administrators. It's intended as an internal tool for the filesystem.
For performance, disk writes do not always take place in the same order they are issued. If the system is interrupted by a power failure or a system crash before it has time to write everything, the filesystem could be in an inconsistent state. For example, if a file is being moved from a directory to another, it's possible that the disk block with the content of the old directory has already been written, but the disk block with the content of the new directory has not been written. If the system halts just at this time, the file is no longer referenced from either directory and is effectively lost.
There are several techniques to avoid this problem (which is usually known as resilience in filesystem design). Many filesystems, including NTFS, use a journal for this purpose. The journal records actions in the order they are taken, and each action is added atomically, so reading the journal always yields a consistent state. There are filesystems, called log-structured filesystems, where the journal is where all the information about the content of the filesystem is recorded. With others, including NTFS, all the information is eventually written outside the log: the log only contains recent information which might not yet have been written in its “normal” place. Reading a file does not access the log, it access the data directly in the normal place. The log is only read at boot time (more precisely: when mounting the filesystem) to finish any action that has not yet been carried out.
Generally, with a journaling filesystem that isn't log-structured, the journal will only contain very recent actions. The journal usually has limited space and old entries can be overwritten as soon as the corresponding actions have been written to disk, which typically takes no more than a few seconds. You may still be able to see old journal entries if there isn't much activity compared to the journal size, but it isn't something you can count on.
Some Linux filesystems (for example ext4) use a log. But Btrfs isn't one of them. Btrfs achieves resilience through copy-on-write. It never overwrites a disk block that's in use. To make an update, it creates a new block with the new data, then creates a new block for any place that contains the location of the block that needed to be updated, then creates new blocks for the places that contains the location of that, and so on. When it reaches the root¹, it ensures that all child blocks are written, then it updates the root. This way, the root always references always valid blocks.
If you want to track file operations, a filesystem journal is not the way to do it, either on Linux or on Windows. The main tools for that on Linux are LoggedFS and the audit subsystem. See Is it possible to find out what program or script created a given file? and List the files accessed by a program.
¹ That's the root of the block tree, not the root of the directory tree. The distinction isn't really apparent at this level of detail.
Given that btrfs is a COW filesystem, it should be always in a correct state unless it was buggy.
Journalling is only needed, if you overwrite data and thus the filesystem could become inconsistent if the write order would follow the idea to make a filesystem fast. Journalling is a way to make non-COW filesysten fast without touching stability.
